In Bitcoin, because you can verify the validity of the entire blockchain and a valid transaction contains proof that the sender authorized it, you can in principle trace your coins back to their origin and have a proof of authorization for each step along the way. This means that if your coins ever end up disappearing, it must be because either a) they were double-spent at some point, and the current longest chain includes the other transaction or b) the block they originated in isn't part of the longest chain. This also means there's no way to end up controlling coins that you didn't control before except by receiving them or by mining a block, which puts limitations on the kinds of attacks possible. (An attacker must legitimately control coins in order to double spend them, for example – they can't just print money.)
That's correct, though it doesn't protect against many kinds of attacks. For example, someone with sufficient hash power can alternately deposit and withdraw Bitcoins at a large exchange and then rewrite the block chain to turn his deposits into double spends. This might undo a large number of transactions made by other people who withdrew from that same exchange. So even though he can't touch Bitcoins that never moved, he could contaminate a huge fraction of Bitcoins that do move. (By invalidating prior transactions that they depend on.)
In Ripple I understand that validators only needs the most recent ledger, meaning there isn't any guarantee that such a chain of proof exists.
Strictly speaking, that's all they need. But a validator can demand whatever proof it wants. Of course, if it doesn't agree with the majority, it won't do much good. But validators can get together to instill any rules they wish for how to determine the valid ledger.
Are there any attacks that have the rough form
... -> valid ledger -> valid ledger ->
-> superficially valid ledger with incorrect balances -> ...
We don't think so. Should this ever be an issue, a validator can adopt a policy to defend. While your policy could be to accept any ledger that has the majority rule, your policy could also be to be the "valid minority" if the apparent majority can't prove the validity of the ledger it claims. It is the validator's job to, in consultation with the other validators, declare the valid ledger. If you don't like a validator's policy, you are free to ignore it.
All of these policies work. If some vulnerability were ever spotted in the policy, it can easily be changed with no need to get everyone to agree on the change. The current code goes with a strict majority and does not demand a chain of proof. We're investigating whether this is the ideal approach.
The advantage of the Bitcoin approach is that the result is unambiguous and (barring bugs like the one that caused the recent split) everyone with the same data should agree on the same result. This does guarantee that if you don't try to move your coins, they stay safe. The advantage of the Ripple approach is that validators can be flexible and you're immune to attacks based on people who gather hash power. If someone does cheat, a consensus can revert the ledger just as was done with the bug that create Bitcoins out of thin air. The disadvantage of the Ripple approach is that unless validators adopt a policy of always demanding proof, you can theoretically lose coins you never moved. Of course, validators could insist on such proof before allowing a rejoin after a split.
Ripple is much more flexible than Bitcoin in this regard. That is both an advantage and a disadvantage.
That is, is there some event like a massive power outage or a network split or colluding validators which somebody could exploit to update balances in their favor? Perhaps it might go like this: a power outage makes it so that a colluding set of validators is temporarily the majority, and they propose a ledger with malicious changes. Several ledger closes go by before the rest of the validators are up again, and when they look at the network they see that the current ledger includes the malicious changes. Because no record of a transaction needs to exist for a balance to be considered valid, there's no way to prove that the new balances are illegitimate, and the malicious ledger looks valid.
Right, that would be the type of attack you'd have to try to make work. It can be defeated by validators demanding proof of a valid chain. We do need to investigate what the right policy is. I think it's that you just go with the majority on startup but that if you see things change while you are running, you demand to see a proof chain and be the "correct minority" if you cannot get it. (Of course, while you remain in the minority among nodes you choose to trust, you have to pronounce the network "broken" this protects those who trust you from transacting on a split network. Failures should not be silent.)
Another possibility might be to demand proof if you've been down for less than a certain amount of time. If you shut down for ten minutes to reboot a server and all of a sudden a majority is claiming something completely different, you probably should try to build the minority. But things would already be fairly broken if it got to that point.
We have a "clustering" capability to declare nodes that you fully trust. This allows a group of servers under common administration to distribute the cost of ECDSA signature checking. If we're part of a cluster, we could go with other nodes in our own cluster on startup. That would get the node back in service faster.
As I explained earlier in this thread, Bitcoin could pretty easily adopt some of the same techniques Ripple uses to deal with disagreement. While you can't really change the rule that the most PoW is the valid chain, you can at least automatically detect when there's disagreement over the longest chain and stop transaction processing sooner, without requiring the manual intervention that was required in the 0.7/0.8 split.
To summarize: There are two types of ways a system can be attacked or fail. One is due to a bug or design flaw. Systems develop resistance to this type of attack by good design, many eyes looking over the design, and over time. But the other way is due to an understood weakness -- one that you defend against but ultimately must accept as fundamental to the design. For Bitcoin, this would be a Finney attack or a 51% attack. For Ripple, this would be some kind of consensus breaking attack. We believe Ripple is less vulnerable to this type of attack because consensus is more flexible. You can choose who to trust, rather than having to trust whoever has the most hashing power, and you can choose how you use that trust, rather than having to go with the longest chain. There can, however, be endless arguments over what the very best way is to use this flexibility, and we will continue to improve it to make these attacks even more unpossible.
