The bitcoin system is based around the "block chain", whose main purpose is to implement a distributed timestamp. With a known set of participants, this is a solved problem (Paxos algorithm); on the public Internet with undefined participant list, it's hard.
One can try to solve the timestamp problem... or one can design a system that doesn't need it.
In a ripple-style system, transactions mostly commute; for the most part, the ordering doesn't matter. Indeed, the only parts that don't commute are where the design commingles what should really be separate levels of abstraction — transactions with automated trading. In the transaction system, each transaction is a collection of increases or decreases to accounts; it does not matter in what order these increases and decreases are made, the final balance is the same. The automated trading does rely on ordering, because it makes decisions based on account balances; but that could and should be a separate subsystem, running at a different level of abstraction, according to the principle of separation of mechanism and policy — and it does not need to be globally coordinated, being instead a local decision of each participant.
Some consensus is still needed, of course; a transaction is not valid unless signed-off by all parties whose accounts are being decreased, which in practice means all parties to the transaction. However, that consensus is now between a small number of parties, which moreover already have at least some pattern of trust among themselves.
Partly inspired by: BoingBoing: BitCoin skeptics and boosters debate
As the linked articles note, bitcoin's "proof of work" probably isn't the most efficient or effective way to do a distributed timestamp, and as some of the comments note, significant aspects are in fact not distributed but rather decided centrally by the development team (hard-coded "known good" blocks).
⇦ pfh's autism hypothesis | ⇨ mechanism vs policy |
