[cryptography] Bitcoin attack
natanael.l at gmail.com
Mon Nov 4 10:37:14 EST 2013
Can't the distributed pool P2Pool easily be updated to account for that?
- Sent from my phone
Den 4 nov 2013 16:33 skrev "Peter Todd" <pete at petertodd.org>:
> On Mon, Nov 04, 2013 at 09:31:04AM -0430, Karn Kallio wrote:
> > The paper "Majority is not Enough Bitcoin Mining is Vulnerable" may be of
> > interest.
> > http://arxiv.org/abs/1311.0243
> > Abstract. The Bitcoin cryptocurrency records its transactions in a pub-
> > lic log called the blockchain. Its security rests critically on the
> > distributed
> > protocol that maintains the blockchain, run by participants called
> > Conventional wisdom asserts that the protocol is incentive-compatible
> > and secure against colluding minority groups, i.e., it incentivizes
> > to follow the protocol as prescribed.
> > We show that the Bitcoin protocol is not incentive-compatible. We
> > present an attack with which colluding miners obtain a revenue larger
> > than their fair share. This attack can have significant consequences for
> > Bitcoin: Rational miners will prefer to join the selfish miners, and the
> > colluding group will increase in size until it becomes a majority. At
> > point, the Bitcoin system ceases to be a decentralized currency.
> > Selfish mining is feasible for any group size of colluding miners. We
> > pose a practical modification to the Bitcoin protocol that protects
> > selfish mining pools that command less than 1/4 of the resources. This
> > threshold is lower than the wrongly assumed 1/2 bound, but better than
> > the current reality where a group of any size can compromise the system.
> I replied on the bitcoin-development email list with what I believe is a
> better solution than presented in the paper. In particular my solution
> returns the attack threshold to 51%, rather than the 25% they achieve:
> Remember that the selfish miner strategy outlined in the paper is
> essentially a way to use knowledge of what blocks miners will be mining
> on, from the "first seen" rule, and the ability to broadcast blocks you
> have mined more widely than other miners. That knowledge and ability is
> then used in conjunction with a small lead (obtainable by chance) to
> outpace the rest of the network.
> By making all miners easily identifiable you make gaining that
> informational and broadcast capability easier to obtain rather than
> harder. The attacker now only needs to connect to every identified miner
> with especially fast nodes. With judicious use of DoS attacks and low
> latency they can still gain the informational and broadcast "upper hand"
> over other miners and carry out the attack.
> Where the paper goes wrong is they don't recognize the fundemental
> nature of the strategy being based on an informational advantage. Their
> "pick a random side of the fork" strategy may work to some extent, but
> it's incomplete and isn't necessarily rational for the miners
> The correct, and rational, approach for a miner is to always mine to
> extend the block that the majority of hashing power is trying to extend.
> The current relay rules don't give you that information at all, but they
> can if we do two things:
> 1) Relay all blocks that meet the PoW target. (as suggested in the
> 2) Relay block headers that nearly meet the PoW target.
> Mining strategy is now to mine to extend the first block you see, on the
> assumption that the earlier one probably propagated to a large portion
> of the total hashing power. But as you receive "near-blocks" that are
> under the PoW target, use them to estimate the hashing power on each
> fork, and if it looks like you are not on the majority side, switch.
> This very effectively defeats the paper's selfish-miner strategy, as all
> miners will very quickly be mining on the block that truly has the
> majority of hashing power trying to extend it. This is also a better
> overall outcome, because it puts the 51% attack threshhold back at 51%
> cryptography mailing list
> cryptography at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography