In the near future, if you're running the standalone client and not running a server, you'll be able to select a list of servers to use. Currently, the client trusts the server for pretty much everything except forming and signing transactions (so your private keys never go to the server).

The protocol is designed so that the client doesn't have to trust the server to tell it which transactions have cleared or what their balances are. But currently the client does trust the server to report this information. In the future, if the client is enhanced not to trust the server in this way, it will need its own list of nodes it's willing to trust to sign a statement of which ledger is the valid, last closed ledger. Validators already issue this signed statement every time a new last closed ledger is produced. So a client that doesn't trust the server would also need a list of validators whose signed statements of the hash of the last closed ledger it was willing to trust.

The client would operate like this:

1) The client gives the server a list of validators it trusts.

2) The server tells the client the hash of the last closed ledger and a collection of validations for that ledger from the client's list of ones it trusts.

3) The client verifies the signatures on the validations and then it knows the hash of the last closed ledger.

4) The client can now determine if transactions have cleared, determine current balances, see offers and order books, and so on just by walking hash chains from the ledger's root hash. No further trust is needed. All the client needs to do is say to the server "I need the object that has this hash" and it can walk to past ledgers, past transactions, account histories, and so on. (And it can query different servers or even future nodes whose sole purpose is to retrieve data by hash, taking pressure off the network.)

The ledger was carefully designed to be sufficiently self-descriptive that it can be "walked" in this way.

Trust that they won't conspire against you, yes.

It's hard to say who really has the decision power of Bitcoin. Is it the key developers? Is it the miners? Is it the exchanges? Is it the community that has to agree on changes? Probably, it's a combination. However, you do have to trust that the people with 51% of the mining power won't conspire against you. And you have no control over who that will be.

The way Ripple works, servers come to a consensus about what order to apply transactions. Basically everything else is subject to deterministic rules. As long as everyone agrees on the ordering of transactions, there's no double-spend problem. If transactions conflict, the first one wins.

Server operators set in their servers who they wish to come to a consensus with. A ledger split in Ripple would be the equivalent problem of a blockchain fork in Bitcoin. So it's important that you try to come to a consensus with other major Ripple players. The math is very forgiving because everyone's main priority (after ensuring that the deterministic rules are followed) is coming to a consensus.

We think this is superior to Bitcoin's proof of work algorithm for three fundamental reasons:

1) While they both require you to rely on other people to make the system work, Ripple lets you choose who to come to a consensus with. You aren't stuck with whoever has the most hashing power. If you pick people in Ripple who misbehave you can simply stop listening to them.

2) Everything validators do is signed with the key by which you can decide to add them to your list of nodes you try to come to a consensus with. So if they misbehave in any way, it will be provable via, say, conflicting signed statements or incorrect signed statements that disagree with everyone else. So you'll have to behave until you get your one chance to attack and that that will be that, you'll be back to square one.

3) The worst case failure should be much less severe. With Bitcoin, the worst case failure is constant double spend attacks and requiring more and more confirmations to rely on a transaction. With Ripple, the worst case failure (that an outside attacker can cause for you, I'm assuming your own trust list isn't massively broken) should be a denial of service attack. You'll see that the nodes you need to come to a consensus with don't agree with each other, and you'll know the network can't reliably resolve disputes. The network could be frozen until it is manually fixed. With Bitcoin, you can't tell what block chain mining pools are building on. If there's a fork, you wouldn't know it. It will take manual intervention to know there's a problem

And while this isn't a major reason, it's also interesting that, while being a trusted validator doesn't give you any superior access to the Ripple network, it does give you a say in which new features are added and which aren't. Ripple has a well-defined change process, and consensus is used to enable new feature sets. If a widely trusted validators votes for a feature (or vetos it) that will carry weight in proportion to how many node lists they're on and how influential in turn those nodes are.

Of course, Bitcoin's algorithm is proven and ours is not yet. I'm convinced it's fundamentally sound. But subtle defects or bugs may manifest, of course. We may have growing pains, scaling problems, and the like. I'm confident we'll be able to fix any such problems, and we have an amazing team, but there's no 100% guarantees here.

We discourage it by having a reserve of XRP that is locked to the account. But obviously we have no say over who opens accounts.

It really depends on whether you see having a currency that can't be devalued as a benefit or whether you would really prefer to trade in fiat. If you'd prefer to trade in fiat but want fast, irreversible transfers across the globe, then Ripple is probably the better choice. Of course, you may have to pay transfer fees and you have to trust someone to hold your fiat for you. That's the cost of using fiat, and maybe when people see that, it will help make the case for Bitcoin to them.

Well, you don't really have to. If they take fiat on Ripple, you'll be able to pay them with Bitcoins anyway. Seamless Bitcoin gatewaying in both directions is high on our priority list. Of course, if they'd prefer to receive Bitcoins, then Bitcoin (or Bitcoin over Ripple) may be the better choice from them.

I'm not sure what you mean. I think you're viewing Ripple and Bitcoin through an unreasonably competitive lens. Ripple and Bitcoin are not going to be like Coke and Pepsi any time soon, where every victory for one necessarily comes at the expense of the other. Unless one or the other fails, Ripple and Bitcoin will strengthen each other for a long time to come.

Is your point something like, "Ripple is so much better than Bitcoin that it will destroy Bitcoin". If so, thanks! But it will probably be a very long time before either's success will come at the expense of the other, if ever. Ripple and Bitcoin are both going after a huge group of people who don't know or care much about either and every person either system gets interested in crypto-currencies and decentralized payments will help the other too.

Giving gateways XRP to give to customers as a way of getting their existing customers interested in Ripple and their new customers Ripple accounts is definitely on our list of possible giveaways.

Essentially, Ripple solves the BG problem by having an intermediate "unable to agree" state and designing the system such that nothing terrible happens if some nodes are unable to agree. If a node isn't confident that it has an agreement with the majority of other participating nodes, then it doesn't report transactions to clients as validated.

That's probably true, despite our best efforts. But really, how much does it matter? It will just mean the giveaway won't be quite as effective as it could have been because it won't get as many users. But we know people are participating in the giveaways just to sell the XRP anyway. It won't make Ripple any less usable as a payment system.

The genesis ledger contains 100 billion XRPs in a known account. See here for the distribution:
https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners#Distribution

Not any way that I know of. There's another thread where I solicited suggestions for a way to make that work and nobody came up with any.

The primary problem is that there's no known way to take Bitcoins off the Bitcoin chain such that they can be returned to it that doesn't require a central authority or have other significant drawbacks. There are a variety of other issues that were discussed in the thread where that was first proposed

That's not the only reason, but that's a very good reason by itself. Getting mass adoption is far from a sure thing. Being able to make it free for as many people as possible for as long as possible significantly decreases the chances that all the develop effort will be for nothing. Not to mention, XRP funds the development and ensures there's a healthy company standing behind the network.

Who would the BTC be paid to? Would those transactions have to take place in the Bitcoin chain? How would you ensure that someone couldn't game the system be being on both sides of that BTC transaction?

Since I don't think that's technically feasible, it's definitely not one of the motivating factors. There are too many unsolved technical problems to making that work, and I don't see what the pitch for this network would be -- "It's just like OpenCoin's Ripple network except there's is free and you have to buy Bitcoins to use ours" doesn't sound very attractive to me.

I'm not opposed to a feature that would let issuers choose to eliminate their ability to raise the transfer fee still allowing them to lower it. In fact, I'll add it to the proposed features list now.

https://ripple.com/wiki/Proposed_features

Once the server is open source, we expect a large number of people to start running the server. As they build trust networks and the system becomes decentralized, we will have to establish a consensus before we can make any change that affects how transactions are processed. By intentional design, the system, once distributed, is very hard to change so that people can rely on it doing what they expect it to do. Right now, we are adding new features rapidly and occasionally fixing bugs that affect transaction processing. Once the server is open sourced, the deployment schedule will have to slow down dramatically.

The design isolates those portions that do require consistency (how the set of accepted transactions affects the construction of the next ledger) from those portions that don't (such as interactions with clients, pathfinding, most of the consensus process) so that as much of the code as possible can be changed and improved without requiring universal agreement. This is much the same as the way Bitcoin works -- you can change the RPC commands you support, the way blocks are stored locally, how you form your own transactions, and so on, without needing community agreement. But any change on the affects of a transaction or any case where you accept as valid a transaction everyone else would reject requires a community consensus, deployment of the new code to everyone, selecting a point at which the feature is enabled, and so on.

The algorithms have been tested in simulation under various conditions including large networks with realistic path latencies. The implementation has been tested in test networks and is currently running the live network. It hasn't been tested on thousands of nodes on multiple continents, so there's always the possibility of growing pains. Having our implementation massively tested at no cost to us is another incentive for us to open source the server as soon as possible. Finding and fixing any growth issues sooner rather than later is also a priority.

Not yet, but we have committed to open sourcing it. The reasons it has not been done yet have been discussed extensively.

It's documented in the Wiki and we've answered any number of detailed questions about how it works.

If you have "one big gateway", it's always going to be a single point of failure. One thing Ripple does to reduce this risk is not allow gateways to freeze individual balances. So if a gateway refuses to redeem for particular people for any reason, so long as they're still in operation generally, those people can exchange balances at that gateway for some other asset. But it's certainly true that some kind of general failure of a major gateway could be a significant blow to the Ripple network. This is one of the reasons we are working to get some gateways going that are operated by regulated and insured financial institutions.

Yes. But if the price of XRP drops, they'll lose the present value of their holdings. They have the same opportunity everyone else has -- they hold a position today that has some value. They can sell it for its present value, or they can hold it in the hope that its value will increase but at the risk that its value will decrease. Anyone can buy XRP at its present value and have this exact same future opportunity/risk.

No, and I don't think anybody knows.

Right now, OpenCoin could create more XRP by modifying the software. However, that would be disastrous to our business, possibly subject us to lawsuits, and so on. So we're not going to. It would be insane. In the future, the network will be decentralized and it will take a consensus of validators to do that. If, in the far future, the majority of Ripple validators want more XRP to be created, nothing could stop them from doing so. That would probably cause a network fork, so it's almost inconceivable. It would be similar to Bitcoin miners getting together and trying to force a change to keep the block reward at 25 bitcoins forever. It could happen, there would be revolts, there would be hard forks, but if enough people wanted it, it could possibly happen.

We originally had planned a way to lock the transfer fee for a particular amount of time and require you to announce a higher transfer fee in the ledger. The whole scheme got unreasonably complex, and we ditched it. We hope gateways will contractually obligate themselves not to raise the transfer fee without sufficient advanced warning. No transfer fee applies when a balance is returned to its issuers and issuers must accept their own balances at face value. So you can't really raise your own transfer fee as a way to make your debts worthless. (You'll just make them less desirable, likely causing people to stop letting you hold their money.)

The nightmare scenario would be if, say, some foreign government declares some Ripple account held by someone who has violated that country's laws and insists we freeze that account. They could perhaps bring an action in a United States court or even threaten the lives of OpenCoin employees. If the network was decentralized, we'd have no ability to freeze accounts or make changes except in our own servers, which would just get outvoted by other servers.

Satoshi could have done that in the early stages of Bitcoin -- he picked the 21 million number. Ripple is still in those early stages. To the extent that people worry that this will happen, that will be a drag on Ripple adoption which hurts OpenCoin. So we have every incentive to make sure we don't have this kind of control.

Currently, your choice of gateways are WeExchange or Bitstamp. Start out by adding three contacts to your wallet:

1) Bitstamp, rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B
2) WeExchange BTC, rpvfJ4mR6QQAeogpXEKnuyGBx8mYCSnYZi

WeExchange uses different issuers for different currencies, Bitstamp uses the same issuer for all currencies. Open an account at either Bitstamp or WeExchange (or both). Log into your Ripple account and under Advanced/Trust, create a pathway to the gateway you've chosen for the currency you've chosen. Set the limit to an amount at least a bit greater than the maximum amount of currency you plan to hold. (Note that if you create pathways to both, you may find that other users transactions push your balance between gateways.)

To get Bitcoins into your Ripple account: Log into your account at the exchange and select Deposit and then Bitcoin. You will get a deposit address. Transfer your Bitcoins to that address. Once those Bitcoins arrive in your gateway account, select Withdraw and then Ripple. Enter your Ripple address and the amount you want to transfer.

To get Bitcoins out of your Ripple account: Log into your account at the exchange and select Withdraw and then Ripple. You will get a ripple account and a destination tag to paste into your client. Use the Ripple client to Send to that address (do not forget the tag). You now have Bitcoins in your gateway account and can send them to a Bitcoin address with the gateway's Withdraw/Bitcoin feature.

We're working to make it more seamless, including inbound and outbound Bitcoin gateways that don't require you to explicitly create an account.

Umm, sure, reserved to the public at large, not to OpenCoin. If in some far future the vast majority of Ripple users want to modify the system to create more XRP, we can't stop them. But how is that us reserving anything?

Can you be more specific about exactly what you think is propaganda and why? I'm honestly having a hard time understanding what the criticism is.

I don't think so. You'd have to suppose that adoption is so widespread that open sourcing the code wouldn't significantly increase it and that would still outweigh the harm done by not open sourcing as we had promised. That seems pretty far fetched to me.

I'll see what I can do about it, but I wouldn't expect it will change anything. You can't refute a conspiracy theory with evidence.

Ripple uses consensus to prevent double spends and validate transactions rather than proof of work.

"Think of a room full of people who all agree with each other. To enter the room, you must agree with them. To disagree with them, you must leave the room. They all sit in this room maintaining continuous agreement on everything. Each of them who is honest puts their first priority on enforcing the rules of the room, their second priority on maintaining agreement with everyone who is also willing to follow the rules, and their third priority on accepting legitimate transactions provided they don't violate the first two rules. The rules of the room make it infeasible to agree to a transaction once a conflicting transaction has been agreed to -- such an agreement cannot be formed and be valid according to the rules."