Hello,
Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.
Best,
Ittay
---
Bitcoin Improvement Proposal
Owners: Ittay Eyal and Emin Gun Sirer
We suggest a change in the propagation and mining algorithm for chains of
the same difficulty, to
On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
Hello,
Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.
snip
2. No new vulnerabilities introduced:
Currently the choice among equal-length chains is done arbitrarily,
depending on
On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
Hello,
Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.
snip
2. No new vulnerabilities introduced:
Currently the
Patrick, could you please explain us why the solution proposed by Ittay
would drop the actual honest miners ratio, becoming so backfire? Thanks a
lot
2013/11/5 Patrick patr...@intersango.com
The ratio of honest miners that mine the first block they see is 0.5
Your proposed solution would
On Tue, Nov 5, 2013 at 1:07 PM, Alessandro Parisi startit...@gmail.com wrote:
I agree with Ittay: when bugs are found, they must be fixed ASAP, expecially
when they affect a sensitive sw such as Bitcon; in IT security, every flaw
that is exploitable in abstract, is going to be exploited in
Thank you very much for your fair response, Sir;
this means that anytime a bug is found in Bitcoin protocol, chances are
that it would take a lot more time to get fixed
2013/11/5 Jeff Garzik jgar...@bitpay.com
On Tue, Nov 5, 2013 at 1:07 PM, Alessandro Parisi startit...@gmail.com
wrote:
I
On Tue, Nov 5, 2013 at 1:55 PM, Alessandro Parisi startit...@gmail.com wrote:
this means that anytime a bug is found in Bitcoin protocol, chances are that
it would take a lot more time to get fixed
Correct. There is significant potential that a fix can create other
problems... and any major
Great paper Ittay, thanks for all your work on this.
Today the threshold is 0% with good connectivity.Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In Section 6 and 6.1 you argue y - 1 but the sybil attack you describe, isn't that more like how *all* sophisticated miners
The conversations that spawned from this paper have been fascinating to
read, but I have a problem with the conclusions. To quote the paper:
The Bitcoin ecosystem is open to manipulation, and potential takeover,
by miners seeking to maximize their rewards. This paper presented
Selfish-Mine, a
Preliminary:
Alice has the ability to hear of a block before all other miners do.
The Problem:
Say Alice built a block, A1, from previous block 0. She doesn't let other
miners know about it. She then works on A2 with previous block A1. Bob on the
other hand is still working on B1 with previous
I don't think choosing the block with the lowest hash is the best
option. The good and bad miners have an equal probability of finding a
lower hash. But after Alice finds a block she can easily determine the
probability that someone else will find a lower hash value that meets
the difficulty
On 5 November 2013 20:51, c...@safe-mail.net wrote:
Possible Solution:
If N amount of blocks built of the same previous block are received within
a time frame of T mine on the block with the lowest hash.
Logic:
In order for Alice to pull of this attack she not only has to propagate
her
On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman jer...@taplink.co wrote:
I think it's a stretch to say 'y' is 0 with good connectivity. Even the
best connected mining pools today are concerned with this 'y' factor.
Check out the following paper for the effect a single node can have on
On 5 November 2013 22:07, Quinn Harris btc...@quinnharris.me wrote:
I don't think choosing the block with the lowest hash is the best
option. The good and bad miners have an equal probability of finding a
lower hash. But after Alice finds a block she can easily determine the
probability
On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote:
If I understand the issue properly, this seems like a pretty elegant
solution: if two blocks are broadcast within a certain period of eachother,
chose the lower target. That's a provable fair way of randomly choosing the
winning block
On 5 November 2013 23:06, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote:
If I understand the issue properly, this seems like a pretty elegant
solution: if two blocks are broadcast within a certain period of
eachother,
chose the lower
On 11/05/2013 08:03 PM, Drak wrote:
On 5 November 2013 22:07, Quinn Harris btc...@quinnharris.me
mailto:btc...@quinnharris.me wrote:
I don't think choosing the block with the lowest hash is the best
option. The good and bad miners have an equal probability of
finding a
lower
On 2 November 2013 22:57, slush sl...@centrum.cz wrote:
Glad to see that there are more and more people wanting to replace
passwords with digital signatures.
Although such method has been already used on other websites like Eligius
or bitcoin-otc, I dont think theres any standard way to
On 2 November 2013 22:14, Johnathan Corgan johnat...@corganlabs.com wrote:
On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote:
Server provides a token for the client to sign.
Anyone else concerned about signing an arbitrary string? Could be a
hash of $EVIL_DOCUMENT, no? I'd want to XOR
Recently, there has been a reasonable amount of discussion about the
continued fragility of the public Bitcoin network on IRC and elsewhere
(1). To this extent, I'm organizing a system of peering between nodes in
the network by creating a system of high-speed relay nodes for miners
and
20 matches
Mail list logo
