We're committed to decentralizing it and we honestly believe that it can only work if it's decentralized. If you don't trust us (and I'm not saying you should) wait until it is decentralized.

What's Bitcoin-like about Ripple is that:

1) Transactions are public and pseudonymous. All system state is public and freely exchanged.

2) Transactions are cryptographically secured.

3) It doesn't require any central authorities once it's deployed. No one person or group will be able force the system to do any particular thing. Nobody will be able to shut it off.

4) The code will be open source. Broad participation in the development will be encouraged.

5) All participants will be able to verify transaction validity if they wish to.

The above assumes we get where we're trying to go. There's no guarantee we'll succeed, but we promise to try very hard.

I'll see what I can do about getting a status page going.

Geez, now I feel like I have to come up with a clever reply, but I'm too tired. Can you just imagine I said something really clever here? How about a free math joke:

Q: What is purple, commutes, and is worshipped by a few people?

A: A finitely-venerated Abelian grape.

Yeah, but it's in Alpha.

The website just sends the client software to your machine which then runs on your machine. Your client gets your wallet from a file on your machine, a blob vault, or wherever you're storing it. So what you're doing when you go to the client page is running the client on your machine. The client can connect to any server. (See the 'Options' screen.) We also plan an installable client so you don't have to download it.

Once the server is available publicly, you'll be able to run the server to add capacity to the peer-to-peer network, participate in the consensus process, and allow clients to connect to your server. The system is massively peer-to-peer among the servers and the servers serve the clients.

You're right. The clients are not peers since they don't provide services to anything and so, to be precise, Ripple should not be described as a P2P network unless you mean the relationship among servers. B2B's not really right either -- if you mean the servers, they are P2P. If you mean the clients, they're not B2B. There may not be any perfect term to describe it. I still think P2P is closest because it behaves just as if it would if it were "really" P2P except that adding a client doesn't add capacity. Some may consider that fundamental.

Yes. It doesn't work well. An attacker will optimize their system for creating the proof of work while legitimate users will have to make do with whatever they've got. Also, an attacker can create proof of works in unlimited supply -- only the rate at which he can produce them is bounded. So if he has enough of an advantage over you, you will never get in ... ever. Then what do you do? Upgrade your computer?

We're basically committed now. We're not centralizing control -- we carefully designed the system to not require any central authorities and to use a democratic consensus process rather than proof of stake. We'll be giving billions of XRP away to try to keep the system free for as many people as possible for as long as possible. We are committed to decentralizing the system.

If you believe it will succeed if centralized, why should we decentralize it? And if you don't believe it will succeed if centralized, why do you think we would centralize it? Or do you think we don't want it to succeed? We firmly believe Ripple will only succeed if decentralized.

You need XRP to create an account (200 XRP per account), to hold in reserve against credit lines and offers (50 per open credit line or offer), and to fund transactions (10 millionths of an XRP per transaction). It's used to prevent spam transactions and ledger bloat.

The point of the giveaways is to allow you to create an account, fund transactions, and test the system to see how it works. Real world applications are still pretty limited but, hopefully, growing rapidly.

We're promoting Ripple as a payment system like PayPal or mailing someone a check. Using it for community/personal credit is possible, but not likely to be significantly useful in the real world for awhile.

While we are working on eliminating a few of the step, the basic way you use it now is like this:

1) You create a Ripple account.

2) You open an account at a gateway (currently WeExchange or BitStamp).

3) You configure your Ripple account to trust the gateway to hold some amount of money for you in some denomination.

3) You deposit funds of some sort with the gateway. They could mean you send them Bitcoins, dollars, or any other currency.

4) You "withdraw" the funds from your gateway account to your Ripple account. You now hold "IOUs" from the gateway in the Ripple system. This works much like a bank balance -- if you have $50 in the bank, that means the bank owes you $50.

5) You can now send and receive money by exchanging your IOUs on the Ripple system with anyone who is willing to take them. You can exchange currencies, switch to IOUs from a different gateway (if that's what you need to pay someone, for example).

6) When someone pays you $50, they do it by making your gateway owe you $50 more. When you pay someone $50, you basically make your gateway owe you $50 less and their gateway owe them $50 more. If you trade USD for Bitcoins, you wind up with your gateway owing you Bitcoins on the Ripple network.

7) If at some point you want to get some of these currencies out of Ripple, you command your Ripple account to withdraw them into your gateway account.

8 ) You can withdraw funds from your gateway account using any withdrawal method the gateway supports. For Bitcoins, for example, they'll transfer them to any Bitcoin address you specify.

This is exactly how exchanges work now. You deposit USD at an exchange and have USD in your exchange account. For the exchange itself, you and someone else swap exchange IOUs so that the exchange now owes you Bitcoins instead of USD. You then withdraw the Bitcoins from the exchange account. Same thing, though there are a few extra steps right now.

The basic idea is that because some people have withdraw on demand agreements with a gateway, they'll value those IOUs at very close to face value. That will make everyone value those IOUs at close to face value.

You mean with an unlimited supply of XRP? That would have us essentially selling every transaction and ensuring the system never becomes decentralized.

If you mean with a limited supply, we'd run out. We'd either have to raise the price, essentially auctioning them off, or strictly limit who can buy how many, which I think defeats the point.

We want to make the system free to many people for as long as possible.

This is actually a very hard problem.

What difference would that make though? If they're scarce, the cost of transactions and the reserve should come down by consensus. If they're plentiful, what's the issue?

The consensus process isn't XRP proof of stake, it will be purely democratic. The consensus process sets the transaction fees and reserve.

Unfortunately, we're not willing to release details before the fact because of the risk that people will game the system. Here is what I can tell you:

The plan is to give away 50 billion of the 100 billion ripples. The rate at which they're given away will be determined by how quickly we can actually give them away and how quickly we believe we can scale the network and maintain its reliability.

Now, speaking officially for OpenCoin: We are committed to being transparent after the fact. We are committed to giving away 50 billion XRP. For each give away, such as the current Bitcoin Forum giveaway, we will publicly disclose at least how many people participated in the giveaway and how many XRP were given away.

We have already proclaimed loud and clear what our intent is to distribute XRP. I think any change in the plan, other than the timing, is very unlikely at this point.

There's all kinds of cool things you can do if people put you in charge and gave you a gun. But you have to take people's freedom away to do it, and that's an awfully high a price to pay. The challenge is to come up with ways to make people's lives better than don't require people to threaten each other into going along with the scheme. Ideally, this time no one would have to get nailed to anything.

I think descriptions of the "interesting" case (how Ripple uses consensus to solve the double spend problem) are getting confused with how the uninteresting cases are solved. There are really three cases:

1) As a non-validating client or server operates: Here, you just collect validations, which are signed statements of the hash of the last closed ledger. The validations are timestamped and sequenced. This allows a client to determine the current ledger which includes things like balances. You can then follow hash chains to get the results of transactions, view order books, and so on without any trust needed.

2) When a new validator comes online: A new validator can determine the current ledger using the same mechanism a client does. The new validator will then synchronize to the current ledger. The validator can also walk the hash chains to ensure that there is a valid path from the last ledger it accepted to the current ledger.

3) The interesting case -- as a validator operates, solving the double spend problem: The validator must already agree on the last closed ledger as described above. Validators exchange proposals that state which transactions the validator believes should be candidate to be applied to the ledger. Once a consensus is reached, the candidate transactions are applied deterministically so that all validators produce the same new last closed ledger. They then sign validations of this ledger (for use by clients and new validators as in 1 and 2 above). The servers then start the next consensus cycle and also collect validations from the ledger they just closed to ensure that nothing went wrong in the consensus process and to provide to clients.

Using my (overly simplified) agreement room analogy, it works like this:

1) There's a room where everyone agrees on the last closed ledger.

2) If you want to disagree, you can, but you must leave the room to do so.

3) If you want to know what the current ledger is, you walk in and ask everyone in the room.

4) If you want to perform a transaction, you read it out loud. Everyone honest agrees that it's valid.

5) If there are any transactions that someone in the room believes is valid and is not in the current ledger, they attempt to obtain a consensus on that transaction.

6) When a consensus is reach, the consensus transactions are applied to the last closed ledger forming a new last closed ledger.

7) Everyone agrees on the new last closed ledger.

8 ) We go back to step 5. Any transactions believed still valid but that didn't get into the consensus transaction set for some reason should now be voted in by every honest person.

9) If people appear to be acting in ways that don't make sense, such as voting no on transactions that have no reason not to be included or failing to validate the correct ledger, you ignore them.

10) Your top priority is to enforce the rules of the room. Your second priority is to achieve consensus.

I don't get it. How are bitcoins and gold different in this regard? Anyone is free to mine gold too. And everyone doesn't have an equal opportunity to mine Bitcoin. For example, some live in areas where electricity is drastically overpriced.

In principle, each user can select their own set of trusted validators based on entites they trust not to collude. The system is designed to be robust even with only minimal overlap.

Right now, you select a list of domains to trust and those domains list validators they believe are independently managed. Currently, only servers need a trust list and clients trust server to tell them what the current consensus ledger is. We are transition to an untrusted server model where clients will tell the server which validators they trust and servers will pass on validations from those validators to clients to convince them that the current ledger is what they claim it is.

Clients only need to trust validators to determine what the current ledger is. They can then walk the hash chains to confirm balances, transactions, and so on.

Servers need to decide which validators they will work to establish a consensus with. So having a good list of validators is much more important if you yourself are a validator. We expect people who choose to be a validator and ask people to trust them to put some effort into selecting the validators they will trust.

I can't tell you today what the scheme will be 15 years from now. If Ripple catches on, it may be domain scraping. Essentially, as you visit web sites, your browser would check if they provide a Ripple validator list. If so, you might click on a button to add them as a validator source. You would then look at validators that were nominated by several of your sources.

Unless your list winds up consisting of almost all colluding validators all colluding with each other, a bad trust list will be easily detected. And even if it does, good servers won't be able to convince you to accept what they claim is the latest ledger. So there would be multiple clear indications that your trust list was broken.

That's correct.

I'm going from memory here, but this should be roughly correct: Every 256 ledgers is a "flag ledger". Validations for a flag ledger can include fields for what you think the XRP cost for a transaction and reserves should be. During the ledger interval after the flag ledger, nodes collect validations from the flag ledger and make their own determination of what the values should be (based both on what they want and what nodes they trust want). Nodes can then introduce pseudo-transactions to change these values into the transaction set of the next ledger. If one of these pseudo-transactions gets accepted, then the fees are changed.

Before the system was named "Ripple", ripples were called "stamps".

We honestly believe we struck the right balance between giving as many people free use of the system as possible and being able to maintain the system and fund its development. This is not a "more is better" or "less is better" thing -- it's a compromise.

Our system would give everyone who participated in the giveaway a free account and millions of free transactions. There's wouldn't. Our system would be promoted and supported by a company with expertise and funding. There's wouldn't. Which system would you rather use?

I helped build a *payment* system with community credit features. Doing it this way allowed it to have no central authorities and (we hope) be nearly free, or free, forever.

I think you're trying to position Ripple as a currency and a competitor to Bitcoin. Ripple was built by Bitcoin people, people who love Bitcoin. That's not what they wanted to do. Look at this from the point of view of the people the system was built for -- people who want an alternative to PayPal or checks.

(Again, speaking only for myself and not as a representative of OpenCoin.)