Quote from: LaggedOnUser on May 14, 2013, 11:33:23 AM

I think there is a possible flaw in the Ben Laurie paper on Bitcoin, called "Decentralized Currencies are Probably Impossible, But Let's At Least Make Them Efficient" (http://www.links.org/files/decentralised-currencies.pdf).

If I may summarize his argument:
1. Bitcoin is inefficient, because it may require as much as 51% of the world's computer power to protect against a 51% attack.
2. Bitcoin solves this problem by doing periodic checkpoints, which are snapshots of the currency at a point in time beyond which its history cannot be rolled back.
3. These checkpoints use some other form of consensus which is more efficient than Bitcoin, but still secure and presumably decentralized, otherwise Bitcoin is not secure and decentralized.
4. He calls this hypothetical checkpointing mechanism "efficient unbounded agreement", and then claims that a more efficient coin than Bitcoin can be built on the basis of that mechanism alone.

The flaw in his argument, it seems to me, lies in assuming that the efficient unbounded agreement mechanism can somehow be separated from Bitcoin as a separate standalone protocol. Checkpointing is merely freezing Bitcoin at a moment in time and refusing to roll back any transactions before that time. Checkpointing relies on the assumption that the original Bitcoin proof-of-work is robust and secure, so that it is quite unlikely that a sustained attack can be made longer than a given period of time on the original Bitcoin protocol, thus it is presumed safe to checkpoint after that time.

However, checkpointing is only a secondary protocol that is not capable of standing on its own as the basis for a coin. Checkpointing is merely a secondary validation of a primary security model. Thus his conclusion, which essentially seems to say that we should throw out the Bitcoin and keep the checkpointing, is false and unworkable.

An analogy might be made with credit card security. Imagine that credit cards have all their existing security mechanisms, plus you can't do chargebacks after 30 days. An analogy to Ben Laurie's argument would be claiming that you can do away with all other card security and simply refuse to accept chargebacks after 30 days, and that would be just as secure as before. That of course would be false, since a limit on chargebacks would just be a secondary security mechanism that can't stand on its own.

I bring this up because the PPCoin paper references this paper and seems to rely on it (http://www.ppcoin.org/static/ppcoin-paper.pdf). Elsewhere I have attempted to criticize PPCoin as well, along slightly different lines (an effort that I am still working on -- see https://bitcointalk.org/index.php?topic=202573.0).

I am not implying that it is impossible to make a more efficient coin than Bitcoin. Also, I am not implying that PPCoin is insecure simply because it references that paper. However, I did want to point out the apparent flaws in that paper's arguments, which if genuine, imply that it should not be relied on.

Ben's argument is quite black and white, where the actual truth is nuanced.

He's saying that the developers are a central point of failure.

My greatest fear is a controversial change that the foundation and most core devs may be in favour of, but many community members may be against.

It's not that hard to propose something that splits opinion, divide and conquer.

If the community remains robust bitcoin will grow in strength. It's one of the strongest open source communities I've seen.

So Ben is right, in that community and developer consensus are a potential point of failure, but same is true of linux etc.

But his mistake is that he assumes that an attack surface remains constant invariant of how many eggs you put in that basket ... ripple is a 100% consensus model, and it's unclear that it will be any more robust than btc ... and may be lest, time will tell ...