[math-fun] Ben Laurie's criticism of bitcoin and suggested replacement
http://www.links.org/files/decentralised-currencies.pdf -- Mike Stay - metaweta@gmail.com http://www.cs.auckland.ac.nz/~mike http://reperiendi.wordpress.com
Quoting from the paper: ------ That is, in the pure Bitcoin model, where "longest chain wins" is the only rule, an adversary with more power than you can always come along at some point with a longer chain that the one you thought was longest, and effectively unwind all coin generation and transactions back to the first mined block. Even worse, it is clear that arriving at the equilibrium state for Bitcoin is incredibly expensive: half of all the computing power in existence must be burnt, in perpetuity, maintaining agreement about the current state of the currency. The Bitcoin developers have recognised this problem, and so they do not, in fact, run the pure Bitcoin protocol. Instead they introduced periodic checkpoints, which are moments at which a snapshot of the state of the Bitcoin currency is taken. Once these snapshots are established, it is not permitted to go back to before the snapshot and revise history... So, the mechanism by which these checkpoints are established must use some other form of consensus, and one which is robust over time. This implies, if you believe what I have said so far, that the protocol for checkpoints must operate through consensus in a known group [in practice, I believe it is the Bitcoin developers], or that the problems of group consensus I have outlined have been solved by some mechanism other than Bitcoin (and one that does not require large amounts of computing power). ------- -- Mike Stay - metaweta@gmail.com http://www.cs.auckland.ac.nz/~mike http://reperiendi.wordpress.com
Oh, I forgot the conclusion: If Bitcoin is, indeed, using a known consensus group, then it has, after all, a central authority (that consensus group), and is not, therefore, a decentralised currency. If, on the other hand, Bitcoin has somehow solved this problem without a centralised authority, then we can use whatever mechanism it uses for agreeing checkpoints as the basis for an efficient solution. [He goes on to show how if you've got a way to establish consensus about checkpoints that isn't centralized, then you can bootstrap that into a decentralized currency that's far more efficient than Bitcoin.] On Tue, Jul 15, 2014 at 12:59 PM, Mike Stay <metaweta@gmail.com> wrote:
Quoting from the paper: ------ That is, in the pure Bitcoin model, where "longest chain wins" is the only rule, an adversary with more power than you can always come along at some point with a longer chain that the one you thought was longest, and effectively unwind all coin generation and transactions back to the first mined block.
Even worse, it is clear that arriving at the equilibrium state for Bitcoin is incredibly expensive: half of all the computing power in existence must be burnt, in perpetuity, maintaining agreement about the current state of the currency.
The Bitcoin developers have recognised this problem, and so they do not, in fact, run the pure Bitcoin protocol. Instead they introduced periodic checkpoints, which are moments at which a snapshot of the state of the Bitcoin currency is taken. Once these snapshots are established, it is not permitted to go back to before the snapshot and revise history...
So, the mechanism by which these checkpoints are established must use some other form of consensus, and one which is robust over time. This implies, if you believe what I have said so far, that the protocol for checkpoints must operate through consensus in a known group [in practice, I believe it is the Bitcoin developers], or that the problems of group consensus I have outlined have been solved by some mechanism other than Bitcoin (and one that does not require large amounts of computing power). -------
-- Mike Stay - metaweta@gmail.com http://www.cs.auckland.ac.nz/~mike http://reperiendi.wordpress.com
-- Mike Stay - metaweta@gmail.com http://www.cs.auckland.ac.nz/~mike http://reperiendi.wordpress.com
participants (1)
-
Mike Stay