Then what does the coloring buy you? This is basically just identical to uncolored Bitcoins. Remember, the ideas was to avoid having to trade on the Bitcoin blockchain.

Without a central authority, who would control the keys needed to transfer the colored coins?

We have the network in a very paranoid mode still where if it thinks anything might be wrong, it stops things and preserves state. The server handling normal client queries thought something was wrong. The error has been cleared. We are prioritizing protecting assets over availability at the moment.

As I've tried very hard to explain, it was mandated by technical reasons. We honestly didn't know any other way to do it. And, to this day, nobody has suggested any. I've explained why Bitcoins don't work, why proof of work doesn't work, why CAPTCHAs don't work, why some mechanism is needed, and why using XRP does work. Please, tell us what the alternative is. It must not require any central authorities once initial distribution is completed. And ideally, it would also be a way that makes it possible for us to make the system free to as many people as possible for as long as possible.

There is a return, it reduces the cost of payments and it helps your friends out.

Social structures will probably have to adjust to make this work, just like they did when people started friending each other on social networking sites. I believe that over time this may change the way people think about money, but I'm not ready to advise people to start using it yet. We need to learn *how* to use it.

Well, right now OpenCoin could do whatever it wants, though that would be a pretty self-destructive thing to do. Once the system is decentralized, it would be equivalent to Bitcoin people agreeing to change the block reward. Can anyone 100% guarantee it won't happen? No. Is it likely to happen? Not at all, not unless something truly awful would happen if it wasn't changed.

For example, one could imagine in the far future if XRP are so scarce that their divisibility is a problem, there could be an agreement to multiply all XRP values by 1,000 to restore divisibility. This is at least sort of creating XRP. (And one can imagine this same thing happening for Bitcoins.)

Adding trust allows someone to owe you money -- potentially money that you might owe to other people. If you extend, say, 1 BTC of trust to me, and I stop using the Ripple system to hold Bitcoins and screw you, you may wind up owing 1 BTC to someone else or losing 1 BTC you held.

At this time, we are only recommending that people extend trust to gateways.

Again, if you extent $10 in trust to someone, you may wind up losing $10 you hold at a gateway and instead having them owe you $10. Instead of getting paid $10 for something, you may wind up having them owe you $10. Issuing trust to someone is like using them as a bank.

On the flip side, you can only hold someone's IOUs if you trust them to send you money. And you can exchange those IOUs for any IOUs they hold in the same denomination, or any credit available to them in the same denomination.

That is correct. You are extending credit to bitinstant since you are allowing them to owe you at least 1 bitcoin. When you withdraw that bitcoin into your Ripple wallet, you will hold an IOU that says that bitinstant owes you 1 Bitcoin. You can then transfer or exchange that IOU on the Ripple system. People who have bitinstant accounts will value that IOU at 1 bitcoin since they can turn it into 1 bitcoin by redeeming it.

Oh, so your whole deal was just to pretend that you didn't understand what people meant when they said "information is scarce". To clarify, when everyone else says "information is scarce" they mean what you mean by "monopolies on certain kinds of information are scarce".

It's equitable because people are paid in proportion to how much service they provide, that service being securing the transactions by piling computational work on top of them. It's as equitable as any other case where someone does work and gets paid for the work they do. It's fair, but it's not some magic great equalizer.

Your analysis is correct. In degenerate cases (small numbers of nodes, sparse trust) the topology works against you as much as the number of colluders. With larger numbers of nodes, the topology works in your favor -- the more nodes there are, the more conspiring nodes required. The cost to acquire a conspiring node may go down with the number of existing nodes, but not linearly.

There is no distinction. If you mismanage your trust, you have failed. It is not so much a moral judgment but more a "this isn't working out" kind of thing.

That would cause you to validate the wrong things.

Yes, exactly. So long as there is agreement, there is no issue. Every honest participant prioritizes agreement over everything but following the rules. (The bitcoin analogy would be that priority one is that blocks are valid. Priority two is that you pick the longest chain.)

The advantage of our scheme is that you get to choose who to trust. The disadvantage is that you have to choose who to trust.

You are, of course, completely right. I should be more precise. You are secure if the majority of the nodes on your trust list are secure. This ultimately devolves into the majority of the weight in your effective weighted trust not conspiring.

In your scenario, where you have trusted only two nodes and those two nodes trust conspiring nodes, you can't become convinced a transaction happened without them having that signed transaction to present. You can't rewrite the past. However, you could be duped into thinking a transaction was applied when it wasn't. You will have signed cryptographic proof that you were deceived. (Hopefully in the future, we'll automate collecting and distributing that proof so you only get to conspire once.)

I largely agree. It comes down to the practical question of which scheme will be more robust in the face of a motivated attacker. I don't think any of us really know that yet.

Someone who attempts a Sybil attack either has to give you what you need or not give you want you need. If they give you what they need, then they do no harm. If they stop giving you what you need, it's just like a netsplit. If they don't give you what you need, then you won't be able to operate.

Since all validations and proposals are signed and timestamped, they can't do a reply attack unless you don't have the correct time. And if they did that, all that would happen is that you would think payments weren't completed that actually were.

If necessary, Sybil attacks can be avoided in a more strong way with very slight changes. Connections use SSL internally and you can connect to specific servers trusted not to cut you off from the network.

Well, you can't really prevent them. But what you must do is detect them and not rely on any transactions if you are on the minority side of a split. You detect netsplits by waiting for validations before you rely on the contents of a newly-generated ledger. So if there's a net split and you are in the minority, you won't get validations from a significant fraction of your validators and thus won't consider any new ledgers fully validated.

Significant netsplits should be pretty rare because all it takes is one server that can connect to each side of the split and the split is healed. I suppose a natural disaster could cut off a country leaving only the clients and servers in that country talking to each other.

Now that I think about it, something like this could be easily added to Bitcoin. If the network hash rate seems to have drastically decreased, you should stop trusting transactions no matter how many confirmations they have. Does Bitcoin do anything about this? Does anyone think it's needed? (It's less of an issue with Bitcoin though. It would take a two-plus hour netsplit to fool you into thinking you have six confirmations if you're in the minority. Ripple aims for faster fully-confirmed transactions so has to detect even transient splits.)

Of course. The design of Ripple doesn't require a central authority. But until it is decentralized, it will effectively have one.

We're not claiming it is decentralized now. We're claiming it requires no central authorities and we are committed to decentralizing it.

I agree. I would say we would also have to wait until a significant fraction of the operating servers aren't under OpenCoin's direct (or perhaps even indirect) control. (For example, until then, if OpenCoin wanted to, it could force a design change that allowed you to create XRP or delete other people's IOUs. Actually, probably not, but you get the idea.)

Again, no central authorities are required by the design and we are committed to a having a decentralized system. We genuinely believe that this is the only way Ripple can actually succeed. The system's security relies on you trusting servers that *aren't* under common control. It is designed to be trustworthy only because it is decentralized. It is not useful if you can't trust it.

I'm honestly not trying to discourage you. These are unsolved problems and good solutions might make all kinds of things possible that are currently very difficult to do. But the first step in solving a problem is realizing that you actually have a problem for which you don't know the solution.

A closely related problem is finding a way to move Bitcoins off the main block chain and into another system in such a way that they can be retrieved by their new owners in the Bitcoin block chain without a central authority. Lots of cool things would be possible if someone solved that. For example, that would be a step to allowing other systems to use Bitcoins to pay transaction fees, Bitcoin nanopayments, and so on..

At the highest level -- you are secure so long as the majority of your trust list doesn't conspire. If you have a bad trust list, you can be lied to about what transactions have been applied by the system.

Think about it this way though -- if you have a 51% attack against Bitcoin, you have to make fundamental changes in Bitcoin. If you have a consensus breaking attack against Ripple, you have to remove the conspirators from your trust list.

Because servers are tracking the validation processes, it's harder to fool servers than clients. If a client is connected to a non-conspiring server that hasn't itself been fooled, then the client will immediately know it has a problem because it won't accept the proofs the server is sending it and the attack will fail.

Absolutely. We have lots of ideas for how we think people will use the system, but we try not to limit how people might use the system. We collect use cases so that if they're at all plausible, even if we don't think they're likely, we can try to make them possible. Because you never know.

Bitcoin behaves just like fiat in the Ripple system. Gateways can hold them the same way they hold fiat so you can transact them on the Ripple network. The same goes for gold.

We use the term "debt" very flexibly. When you have $1,000 in a bank account, the bank owes you $1,000. The bank offers the service of owing you money. Ripple "debts" can also be viewed as someone holding someone else's money.

This doesn't work as well. I'm not lying to you. We really worked hard on this problem and implemented the best solution we could come up with.

First, IP addresses are useless. You can only prove your IP address to someone you cannot to directly. Expecting clients to connect directly to every validator so they can see their IP address doesn't scale. You could have a central authority to which you connected and received proof of your IP address, but we're committed to having no central authorities. A malicious node could simply claim it got transactions from many different IP addresses and thus little proof of work is needed. If you make the node do proof of work to get other people's transactions in, this becomes an attack vector.

Account address only works if accounts are scarce, which gets you back to the same problem of how to keep accounts scarce.

CAPTCHAs don't work because you need a central authority. How do you prove to a machine that you solved a CAPTCHA for another machine not under common administration?

No, because someone who did that would wind up divesting themselves of their ability to attack the network. In a PoW scheme, an attacker doesn't lose anything by continuing to attack. Also, in the XRP scheme an attack is only possible by a stake holder and only in proportion to their stake. In a PoW scheme, attacks are equally possible to non-stake-holders, those most incentivized to launch them.

All you can do with XRP is overload the network and deny service. To do it, you have to keep putting more XRP behind each transaction than those you're trying to keep out are willing to put in their one single important transaction.

You would have to find a gateway you trusted sufficiently. Ideally, we'd have gateways that were regulated financial institutions insured by governments. Since gateways always hold fiat that they owe to someone, this should be possible because it fits an existing regulatory model.

You do have to manage risk with Ripple. That's the tradeoff for being able to use fiat currencies in Bitcoin-like ways.

The number of servers doesn't matter. What matters is the number of keys you have that other people have chosen to trust.
We have a lot of ideas for how to manage this. But we won't get to decide. We can put forth our solution and people will be free to use it or not. Over time, this will probably need to evolve.

We have several different ideas. Here are three of them:

1) Domains can publish lists of validators at a known URL. You can choose domains to trust. You periodically refresh the list of validators and extend trust based on how many such lists a key appears on. (This is essentially the current model.)

2) When you browse the web, your client could check for domains you were visiting that offer validator lists and then you could click to add their published list of validators to your own.

3) People who use the Ripple system, such as major gateways, could run validators and publish lists of validators (including their own) that they assert are not under common administration.

You genuinely want to find as many validators as you can that are not under common administration. You want to do whatever you can to avoid "cronies". The only failure mode is if you wind up trusting a bunch of conspirators.