I have just over one million XRP.

The protocol is documented. The transaction formats are document. The client is open source. All transactions are published along with the precise changes they've made. All network state is public. The network requires no central authorities. Pretty much all technical questions about the network's internals are answered. You don't need OpenCoin's, or anyone else's, permission to open an account (assuming you have $1), operate a gateway, operate a bot, perform transactions, and so on. While OpenCoin could attempt to exercise operational control over the network, OpenCoin has never done so and never intends to do so. (Other than to add features, change reserve levels, and so on to maintain the network. But never to target an individual or group.)

That's correct. If we assume one of them is honest and the other one is dishonest, then the honest node has only dishonest validators on its list and the entire rest of the world is colluding against it. It would be crazy to trust the results of a transaction under those circumstances.

Ripple prefers to fail by telling you that it can't meet its requirements rather than silently letting you rely on results that are in fact unreliable.

Validators don't tell you that someone was double spending. Validators don't validate transactions. All validators do is work cooperatively to agree on candidate transaction sets and sign the network consensus ledger. Bob will not deliver anything to anyone until the transaction is in the network consensus ledger and the majority of validators have committed to it. If there is not a single network consensus ledger that has a clear majority of validators, nobody will consider any transactions validated.

Each ledger is built on the prior ledger and has a hash back to it. There's no way validators can later invalidate some prior transactions. For a new validator to start validating, the first thing it does is sign the network consensus ledger. You're presuming a new validator has somehow come with a new ledger. They can't do that.

I'm really trying to be polite and honest with you, but you are making it extremely difficult.

Bob's client will determine the network consensus ledger and consider the transaction validated if it's either in that ledger or in a prior ledger. The network consensus ledger is determined by checking valdiations which sign the hash of the entire ledger. The exact method is a little complicated and has a few different cases, but the basic idea is that you're looking for a ledger that has been validated by significantly more than half of the validators on your UNL. Until you can find such a ledger that includes the transaction (possibly in a prior ledger) you do not consider the transaction validated.

Seriously? You're going to repeat this as if you've never said it before and neither address nor even acknowledge the responses I've already made to this exact same point?

Yes, we're not yet as open as you would like us to be. But we are already more open than pretty much every other payment system out there.

Right, that's why there's a consensus process. The network comes to a consensus on a set of candidate transactions. Whichever transaction first gets included in such a set "wins", unless both do in which case a deterministic rule chooses the winner.

A network consensus is a consensus of the entire network as a whole. If Charlie and Eve are the network and reach a consensus, then that's a network consensus. Until Charlie and Eve reach a consensus, neither of them will consider any transactions confirmed.

I guess so.

There aren't validators for specific transactions. Validators validate the entire ledger as a whole. Nobody has to ask them to do this, if they want to participate, that's what they do. If they don't do that, then they aren't validating.

Oh, wow. No, you totally misunderstand the process. Validators validate *ledgers*, not transactions. A ledger contains the total state of the entire Ripple network.
http://bitcoin.stackexchange.com/a/7563/85

That's not at all how Ripple works. You treat a transaction as confirmed if it's in the network consensus ledger or any prior ledger.

I have that alert off. I updated my answer as soon as I saw your answer.

What do you think of Ripple as a payment system for fiat currencies and as a platform for social credit?

I don't agree with the premises of this argument, but even if I did, the argument seems bizarre. If XRP is inferior to BTC for commerce, are you saying commerce will switch to it anyway? If you're saying XRP is superior to BTC for commerce, and you also see Ripple as primarily a Bitcoin competitor, aren't you conceding that your opposition to Ripple is an irrational preference for an inferior system?

I give up. How do you know this?

No, validators don't sign transactions. They just sign proposals and validations of ledgers. None of this information really needs to be stored unless you're analyzing the historical behavior of validators. All you typically care about are the validations for very recent ledgers. You get to historical ledgers by walking the hash chains.

We have a distributed storage system on our roadmap so that servers can agree to hold pieces of the total network history. We're not at the point where that's needed yet.

We don't see ourselves as competing with Bitcoin. And I don't understand why you think getting community input earlier in the process is a bad thing. Nobody wants Ripple to be open and decentralized more than we do. We understand that not doing these things is a drag on adoption and creates potential hazards. We are in complete agreement about this and your constant pretending that this is some kind of disagreement seems somewhat dishonest.

We 100% agree. This is why Ripple will be superior to other payment systems. Once the source code is open and the network is decentralized, these kinds of things cannot happen. These kinds of protections will be structurally guaranteed.

It was very difficult to design a payment system that required no central authorities. Many problems could have easily been solved just by having some authority make decisions. Why do you think we went to all the effort to design Ripple the way we did? We learned a lot from Bitcoin.

If a transaction is not validly signed, even if it gets in a consensus set, it still can't be applied to the ledger. If a conflicting transaction is already in a prior ledger, then again, the transaction can't be applied even if it gets in a consensus set (this is basically the definition of "conflicting"). The consensus process only orders transactions to prevent disagreement and double spends. It can't make a transaction valid if it doesn't follow the rules.

So what's the case where this is an issue? If both versions of the transaction are validly signed and neither has yet been included in a fully-validated ledger, then who cares which one gets in?

If you want to change currencies, you need to convert. Otherwise, you're just depositing and withdrawing.

Just make a payment to yourself. It will tell you how much it will cost you.

BitStamp IOUs are valued by many people at very close to face value. A $1 BitStamp IOU is basically as good as a dollar.

Like Bitcoin nodes do, all Ripple servers flood transactions across the network. When a Ripple server receives a transaction, it performs the following operations:

1) It checks if it has ever seen this transaction before. For now, assume it hasn't.

2) It checks if it has received the transaction from a cluster peer (server under common administration) that has already checked the signature. For now, assume it hasn't.

3) It internally queues the transaction to have its signature checked and puts the server it received the transaction from on the transaction's exclusion list.

4) If the transaction is received from any other servers, those servers are added to the exclusion list for the transaction.

5) When the transaction gets to the head of the line, the signature is checked. For now, assume it's valid.

6) If the server is able to, it checks if the transaction can apply to the current ledger. If not, it will not forward the transaction.

7) The server forwards the transaction to every server connected to it that is not on the transaction's exclusion list. When sending to cluster peers, it sets a flag indicating it has already checked the signature.

If so, what's your theory for why we did it? Are you just arguing this point because you hate us or are you really committed to this argument?

We were pretty clear from the beginning that we would support changes to transaction fees and reserve levels that would keep the system cheap. The price of XRP had gone up by a factor of nearly four. I don't think anyone believes it had any significant inflationary effect -- maybe it increased circulation by .04% but in exchange it decreased the cost of entry by a factor of four.

The validators just forward the transactions to each other and each one will include the one it saw first in its initial proposal. One of three things will happen:

1) One transaction will get a majority and the other won't. In this case, that transaction will be included, permanently conflicting out the other.

2) Neither transaction will get a majority. In this case, servers that have seen both transactions (which should be almost all of them) will pick a winner based on a deterministic rule. The transaction that wins by rule should get in during the next round.

3) Somehow, both transactions get a majority (doubt this will ever happen, but suppose it does). In this case, a deterministic rule again determines which transaction gets in.

Really, all you need to do is agree on the order of transactions. Validators do that by agreeing on candidate transaction sets in distinct chunks.

Distinct Ripple networks (if they exist) don't have to agree on anything. If you have validators who have no validators in common, you have distinct networks. To join a network as a validator, you must agree to reach a consensus with some subset of the validators in that network. You also take on a responsibility to manage the set of validators you try to reach consensus with.

I expect, at least for awhile, the Ripple network to have a list of "core validators", likely with a few run by OpenCoin, at least one from each of several major gateways, and probably a few run by well-known groups such as universities and where nearly every other validator has nearly ever validator on that core list on their own list.

Domains (like 'ripple.com') can publish a list of validators they recommend and other validators can select a list of domains to gather validators from. This permits other people to manage some portion of your validator list if you wish to defer that to someone else.

In the event of horrible neglect in maintaining validator lists, long before the network actually split, your node would report that it was no longer seeing a supermajority among its validators and would stop validating. You can pretty much only have an actual split if you start out in a broken state and never converge at all. This is because in order for a split to hurt you, you need to wind up on the minority side of it, which means you won't be seeing anywhere near the number of agreeing validations that you expect.

Absolutely. We change the rules all the time -- primarily to add features.

You're talking about the account reserve. That actually wasn't a rule change but simply the result of the execution of a transaction that changed the reserve, which is stored in the ledger. This certainly wasn't a stealth change, in fact it was widely requested and, as far as I can tell, didn't harm anyone's interests.

There was no change to any rule. The rule operated the same, just on a changed ledger. However, we had fairly recently added the logic to negotiate the change in the reserve level. Had someone not updated their software to support that change, that would have created a hard fork.

To prevent this problem in the future, we are almost finished implementing a coordinated change process. The only time this will cause a validator to be unable to continue is if a supermajority opts for a change that the validator doesn't support. The change process will have built in delays so you will know at least two weeks before adoption that a rule change has a significant chance of being adopted. That should give people time to realize the change is likely to happen if nothing changes, analyze the code, and make a public case against the change if it's a bad one. Validators will be able to "veto" changes if they believe they are harmful to the network. The current plan is for a node to vote to support a change if that change has held 80% support for two weeks. Support is, basically, yes votes minus no votes out of the total.

Sorry, didn't see these.

Every validator signs every ledger it wishes to validate, that's what validators do. Right now, all validators are run by either OpenCoin or those working closely with us. But that will change.

We'll probably have to wait for the source code to open to make this argument academic.

Anyone who wants to can be a validator once the source code is open. Validators participate in the consensus process (assuming people listen to them). They judge what is a valid transaction by applying the network rules, checking signatures, and so on.

They are subject to change by supermajority. Validators participate in the rule change process -- again, to the extent that others are willing to listen to them.

Gateways have no control over how Ripple transactions take place. They can, of course, refuse to honor their commitments outside the Ripple network. This will hurt those, and only those, who chose to trust that gateway.

Gateways and validators have nothing to do with each other. As far as the Ripple network is concerned, gateways are just accounts that issue transactions that follow network rules just like everyone else.