We 100% agree. That's why we designed Ripple not to require any central authorities and why we're working to open source the server code.

What are you referring to? We do change network core rules all the time, primarily to add features, but what do you think was a "stealth" change?

The level is gradually increased to speed convergence. 50% for the initial operation was chosen at first arbitrarily -- the choice easiest to justify and the one that seemed the most "fair". But then simulation showed that it avalanched the fastest.

If you pick a number much higher than 50%, you don't have as much room to ratchet up, and that can cause pathological behavior. If you pick a number much lower than 50%, you can find a transaction in the consensus set that can be hard to acquire because you aren't connected to nodes that have it.

Yes, you switch to the majority valid ledger.

The node basically uses the following algorithm:

1) It switches to the majority of the ledgers it has not rejected. But it does not endorse that ledger.

2) The node tries to determine if that ledger can be endorsed -- determining whether it's a valid following ledger or not.

3) If the node determines the ledger is invalid, it rejects that ledger.

4) While this is going on, the node keeps tabs on any other nodes that have changed their position.

Over time, more and more nodes will veto any invalid ledgers in the mix and soon all honest nodes will be endorsing valid ledgers. The valid ledger with the most endorsements will eventually win.

This doesn't take nearly as long to actually happen as it might sound like. The ledgers will tend to be very, very similar and only differences are analyzed.

Until there's a clear majority, no transactions will be considered confirmed. We'd rather stop than tell people they can rely on information that's not reliable.

Nodes have an avalanche algorithm to restore the consensus process. Typically, there will be one ledger that at least has a slight majority and the vast majority of nodes on that ledger will stay with it and the vast majority of nodes not on that ledger will switch to it. The result of the next consensus round after that happens will then get fully validated.

Correct.

Currently, it treats its own validation as no different from any other validation. If no ledger gets a clear majority, then it won't consider any new ledgers as fully validated until one does.

This works perfectly for servers. However, we plan to modify this behavior a little bit primarily to make things easier for clients. Currently, clients trust their server to tell them which ledger is the most recent fully validated ledger. We want clients to not have to trust the server they connect to. Under the current scheme, that would mean the client would need to see a significant number of validations (and check all their signatures) to become convinced that a particular ledger did in fact get a significant majority.

The planned modification would change the logic as follows:

1) When an 80% consensus is reached, the server terminates the consensus process and builds the next ledger.

2) The server issues a "provisional validation" for the ledger it builds as a result of applying the transactions it thinks are in the consensus set. (This would actually be a new form of proposal and not an actual validation. It probably should be called a "final proposal".)

3) The server goes on to the next consensus process.

4) When a ledger receives sufficient provisional validations to convince the server it's the network consensus ledger, the server only then signs a validation.

This would have no effect on the way servers currently determine ledgers are fully validated. However, it would allow clients to become firmly convinced a ledger had majority support without needing a large number of validations. Each validation now conveys much more information -- the server didn't just build the ledger as a result of the consensus process, it acquired confirmation that a significant number of other nodes also terminated their consensus process at the same point.

This would also protect better against a possible class of bugs where servers might somehow agree on the previous ledger and the transaction set and nevertheless somehow build a different ledger as a result. Imagine, for example, some software bug that causes 32-bit code to produce different results from 64-bit code.

This also makes validators routinely make stronger commitments making it harder for them to claim that a deliberate bogus validation was just a result of unusual conditions.

When the consensus reaches the 80% level, the node stops trying to reach a consensus on that particular set and computes the next ledger assuming everyone else has reached the same conclusion. Someone has to do this first or nobody will ever do it, and the person who does it first can't know for sure that everyone else will do it. This strikes a balance between not taking infinitely long to assure a consensus and not thinking you have a consensus when you don't all the time. At that point, the server moves on and tries to get a consensus on the next ledger assuming that it was correct and everything will work out fine. Basically, the server uses the consensus process to decide which ledgers to validate itself.

Additionally, the server has a "validation gate". This tracks the point in the ledger chain that the server considers fully validated. This is what it reports to clients. To pass the validation gate, ledgers must be validated by other servers. The server has a "validation quorum" that should be slightly more than half the number of validators it trusts. The server listens for validations and allows ledgers to pass the validation gate if they have sufficient validations. A server will do this whether or not it is itself publishing validations.

Once can prove mathematically that theoretically you can go on forever without ever having a consensus. But it's like flipping a coin until it comes up heads. While one cannot place a finite bound on the amount of time it will take, this presents no practical obstacle to actually doing it consistently in a reasonable amount of time.

It's actually trivial -- if there are, say, 1,000 generally trusted validators and you see validation from fewer than 700 of them, you might be in the minority. This has been implemented in the server about a month ago, the wiki is just out of date. The results of the Ripple consensus process are never sent to clients directly as verified. The ledger must pass a "validation gate" before it's considered confirmed and this validation gate will never be passed if you're in the minority because you won't get back sufficient validations.

In contrast, if you're in the minority, you won't know until manual intervention with Bitcoin. If the world splits (as it did recently) people who are on the minority blockchain have no way to know that they are transacting on a block chain the rest of the world does not think is the longest chain. At best, you could statistically infer you were in the minority eventually based on blocks being found too slowly.

Bitcoin could adopt the method Ripple uses to solve this problem. Major mining pools could periodically broadcast a signed object stating the hash of the tip of the blockchain they are currently building on. You could then know if you were in the minority.

First, the BTC has to be in your Ripple account. If it's not, use a gateway to withdraw to Ripple.

We don't have a "pay to self" link or conversion wizard yet, so there's an extra step:

1 ) You open the client.

2 ) You log into your account.

3 ) You select 'Send'.

4 ) If you added yourself to your contact list as "self", type "self" for the destination account. Otherwise, paste your own account in.

5 ) Enter the amount of USD you want to buy. Select USD from the currency dropdown.

6 ) Wait a few seconds for the pathfinding engine to find the best deal it can for you using all the liquidity in the Ripple network.

7 ) If the number of BTC it says it will cost you sounds good to you, push 'Send'.

8 ) In about four seconds, your BTC will be gone and your Ripple account will now have USD.

You now have USD in your Ripple account. If you want it elsewhere, withdraw from Ripple.

I agree. That's a better solution. We have provable association between accounts and domains already. Thanks again. (We had discussed proof of stake for validators in the past, but we kind of forgot about it.)

It's not likely to happen on an organized, large scale through pools and the like if the community considers it an illegitimate tactic. Hence my question. Some might argue that it's theft, fraud, criminal abuse, or the like.

Are you saying that launching a 51% attack on a currency is a perfectly legitimate tactic for advocates of a competing currency to employ?

The secret is to never make an argument you don't believe or can't rationally defend and to concede when you are wrong as quickly as possible rather than digging yourself in further. I have also learned that extending people an almost unreasonably strong presumption that they are arguing in good faith goes a long way as well. The range of honest disagreement is much broader than generally appreciated and as long as you're not talking about religion, most people can be reached by reason eventually. You just have to keep trying.

The load difference of being a validator over a tracking server is negligible, it's at most one ECDSA signature per second and typically much less. People will run tracking servers because there's no other reliable way to get a high-speed pathway into the Ripple network. That will mean gateways and arbitragers will be validators too. Also, being a trusted validator gives you a say in the process by which new features are added to the network.

That's true. It's akin to running a Bitcoin hot wallet. Validators can easily rotate their keys. Once the network is more distributed, you'll have to compromise an awful lot of keys to do any real harm.

People will do that work because they want to use the system. Miners have to mine, but they don't have to provide blockchain downloads. But they still do.

I don't care. If you're being two solid, reliable validators, then that's great. That's twice as great. If at least one of them is crappy and unreliable, then why do I care that they're both you?

This is actually a theoretically plausible attack currently. Thanks for noticing it. It's not difficult to fix -- we can either check the key with others (so we have others to establish he gave out the key) or we can force him to sign the key with a key traceable to him (say, issued by a CA).

You're correct. We need an undeniable way to associate keys with the identities you trust. It's not difficult to do, it just needs to be done.

If you're talking about the personal/community credit model, there's no reason you should mind. In this model, you would extend me $50 credit for only two reasons:

1) You are willing to lose up to $50 to help me out. This is not that unreasonable. If a friend called you up and asked you to come over and help them move some things, you probably would, giving them $50 worth of labor. So lending them $50 when they need it is not out of the range of what friends do. (Especially since Ripple "makes" them automatically return the favor if they are able to.)

2) You want to hold my IOUs because you can use them to trade with others in my network.

In either case, you should be perfectly happy for me to have a negative balance. In the first case, you are helping them out, the very thing you were trying to do. In the second case, you've acquired IOUs you can spend, the very thing you were trying to do.

You will also make be able to make a circular payment to settle inside the system directly, assuming they hold any asset of value denominated in the same currency. This isn't implemented in a way that makes it easy to do yet, but it is planned.

This will require some social changes to work. People will have to be willing to be a little bit more open about their finances. These changes may not happen, but if you look at things like Facebook and texting, they also required social changes and they caught on. So who knows. I hope Ripple gets adopted as a payment system and gradually changes into something more like this.

Then you would be two validators. If either validator wasn't behaving rationally, people would just stop trusting it.

To do any real harm, you'd need to control a significant fraction of the validators that people trust. Then it'd be much like a Bitcoin 51% attack -- except after all that trouble, people would just stop trusting you and you'd have to start over from square one. Whereas, with a 51% attack on Bitcoin, it's much harder to recover. (Though not impossible, of course.)

With Bitcoin's proof of work based algorith, you have to trust that the majority of mining power will not collude against you. With Ripple's consensus algorithm, you get to choose the validators that you trust not to collude against you. Admittedly, this has disadvantages as well -- if you choose very badly, you could suffer for it. In realistic scenarios though, I don't think it's that hard to choose wisely. And the attack is so hard to make and gains you so little (just a denial of service attack unless you control the *vast* majority of validators), I don't think anyone is likely to bother.

Not really a PKI or a web of trust. The simplest way is to publish it using HTTPS. Look at https://bitstamp.net/ripple.txt for example.

Why would they need your verification key at all? If you mean to process your transactions, it works much the same way as Bitcoin. Your "account" is a hash of the public key and transactions include the public key in them. If you mean you're acting as a validator (which is absolutely not needed to introduce transactions) then they would get your public key from whatever source induced them to trust you. You can publish it through HTTPS.

Everything is either signed or sent to a node who already knows the hash of the item it wants because it was referenced by something signed, so you can't send a fake anything anywhere. Basically, consensus just determines the order in which transactions are applied to resolve the double spend problem. Once a transaction is applied, conflicting transactions are blocked.

Candidate transactions must be signed by the account that issued them. Validations and proposals must be signed by validators you've chosen to listen to. Otherwise, you just ignore it.

Why would anyone care what they say? If you mean an attacker who builds trust, it's the same as a 51% attack on Bitcoin where the person builds mining power. Except in Ripple you can just choose to stop trusting them whereas in Bitcoin, you have a real problem.

You're correct that, if they built trust, this would create a temporary denial of service attack. But their bad behavior would be obvious and provable, so people would just stop trusting them. Given that the effort to do this is so great and the payoff so small, it seems unlikely anyone will bother. You're correct that Ripple is more vulnerable earlier on.