A dense web of trust is only needed for credit. Otherwise, there just has to be at least one path with enough liquidity for any given transaction.

If you want to setup a local gateway to help your friends get cash into and out of the system, you can. Here's what you can do:

1) You set up your account to trust at least one gateway. Your friends pay you IOUs from any gateway you accept. You hand them cash.

2) Your friends set up their accounts to trust at least one gateway that you do business with. You pay your friends IOUs from any gateway they accept that you support.

The downside of this setup is that it doesn't allow you to grow into more of your own gateway, but it also doesn't require anyone to trust you. If you want more of a growth potential and think people would be willing to trust you, you can do this:

1) You set up your account to trust at least one gateway. You setup 1-to-1 offers between your own IOUs and IOUs at at least one gateway.

2) Your friends give you cash, you pay them with your own IOUs. You require them to trust either you or at least one gateway you support.

3) Your friends can pay you with either your own IOUs or IOUs from any gateway you support.

4) You try to encourage your friends to hold your IOUs rather than the IOUs of an other gateway. You can do this by keeping your transfer fees lower than that of other gateways. You can do this by convincing them that the risk that you, someone they know, will default is low. With your IOUs, they can costlessly switch to the IOUs of any gateway you support (so long as you aren't "out of stock").

You don't need a dense web of trust. All you need is every account to trust at least one major gateway and healthy paths between any two major gateways. And even if you don't have that, unless an account is an island, you'll almost always still be able to find a usable path.

We all agree that unpredictable monetary changes are bad compared to similar ones that are predictable.

I think we all agree that anything that can't be predicted is likely worse for the economy than anything that can be predicted. The majority of the economy already operates with money whose value can't be well predicted and commodities whose future values can't be well predicted. To suddenly say this is an argument against deflation is unfair.

The Ripple system's rules control the flow of IOUs. You don't have to extend trust to someone to take gateway IOUs from them. You can use gateway IOUs like Bitcoins, handing them around with no concern for the fact that the gateway has withdraw on demand agreements with some people. You can pretend the IOUs just have value because people value them. You don't have to extent trust to anyone but the gateway since you're only exchanging the gateway's IOUs.

Basically, a reliable gateway's USD IOUs act much like Bitcoins except they track the value of the dollar so long as the gateway remains reliable.

(A gateway has the option to restrict who can hold its IOUs to its customers. So you still might need to open an account with the gateway, choose a gateway that hasn't enabled this feature, or use an account "in front of" a gateway that offers 1-to-1 exchange for the gateway's IOUs. This only restricts who can *hold* the gateway's IOUs, it doesn't restrict who can use the gateway in a payment path.)

Why do you say that?

That shouldn't be possible. Should XRP become scarcer, the XRP cost of a transaction can be reduced by consensus. If need be, the divisibility can be increased. (Currently, XRP are divisible into millionths called 'drops'.)

When the network is flooded, it raises transaction fees automatically. So anyone who wants to keep the network flooded will have to continue to supply greater amounts of ripples to do it.

Say the network can handle 50 transactions per second. And say you have a very important transaction that you need to get through. To lock you out of the system, an attacker would have to flood the network with 50 transactions per second, each consuming a transaction fee equal to the most you're willing to pay to get your transaction in. Essentially, Ripples serve as something scarce that can be used to auction off transaction slots when the network is busy, whether due to legitimate load or due to abuse.

OpenCoin will be giving away at least half of the XRP as the system is deployed and scaled. For now, you can post your Ripple address on the Ripple forums, here, in #ripple on Freenode (I think it is) or any number of other places. There are a few people watching for them (I'm not one of them).

Maybe try looking at it from a merchant's point of view. They pay 2% to take credit cards. That's equivalent to losing 7 days gross revenue a year.

I don't see the connection you see between personal credit and exchanges. Perhaps you're not aware how complex, expensive, and slow cross-currency payments currently are. It's a huge real-world problem. There's a similar problem with remittances. Maybe you don't have any problems it solves, but there are plenty of people who do.

And, long term, I think personal credit may revolutionize money.

They don't have to use its full capabilities from the beginning. It just has to do something important better than they can currently get it done.

Right, but that only works if you want Bitcoin on one end of the transfer -- though you don't get instantaneous competitive exchange rates and you're reliant on a system that isn't open source, does have central authorities, can arbitrarily freeze your account, and so on. There's always a risk that the fiat ends of the transactions will be reversed, so you have to pay someone to take that risk. You also can only store value in Bitcoins, which is not such a bad idea right now, but it may not always be that way. If you use it for a cross-currency transaction (say dollars to Euros), you get hit with a commission on both exchanges too.

This conversation is making me uncomfortable because I feel like you're forcing me to unfairly criticize Bitcoin by unfairly criticizing Ripple. For Bitcoin to succeed and thrive, people need to accept Bitcoins as a means of exchange. Once Bitcoin inbound gateways are working, you'll be able to pay any merchant who takes fiat currencies in the Ripple system with Bitcoins, they'll get dollars in their account, and you'll get competitive exchange rates with no commission on the exchange.

Bitcoin doesn't allow people to pay each other in fiat currencies or across currencies. If you wish to transact only in Bitcoins, then I agree with you, about all Ripple offers is community credit. Think of Ripple as a way to make dollars more like Bitcoins. (With both the advantages and disadvantages that entails.)

That's what gateways are for. A gateway is a company who enters into "redeem on demand" agreements with large numbers of people. They serve as gateways to get money into and out of the system. As soon as enough people hold IOUs from more than one gateway and are indifferent to which gateway's IOUs they hold (or arbitragers provide liquidity at a profit), then most paths will be user->gateway->intermediary->gateway->user.

All I can say is wait and see.

We don't see personal credit as a major application for Ripple in the short term. We see it more as a competitor to things like credit cards and services like PayPal. I agree that community credit is hard to use and understand, but I personally believe that in the long term, it could revolutionize money.

Just decide how many lunches you want to allow each coworker to owe you. When someone buys you lunch, you pay them one lunch. They now either hold a "1 lunch" IOU from you or you've destroyed an IOU they held from you. If I owed you a lunch and someone owed me a lunch, you could take that IOU from me in payment and use it to get someone else to buy you lunch.

Yes. They would have to allow you to owe them $20 on the Ripple system, and then you would pay them $20 (in your own IOUs). They would then consider the $20 debt novated by the IOUs in the Ripple system. (God bless you! I've been looking for an excuse to use the word "novated" for more than two years now.)

We're planning to begin giving away XRP shortly. We're currently releasing them slowly to manage load and use as we work through deployment and scaling issues. Stay tuned.

The key insight is to see that there's a one-to-one correspondence between 128-bit strings and 256-bit palindromes.

No, they refused to exchange for currency. The reason they couldn't exchange was because they had no functioning medium of exchange, not because they had an inflating currency. Unpredictable or absurd inflation or deflation can make a currency unusable. (Which is no problem if there are other currency options but a big problem if there aren't.)

It affects us equally because it reduces the value of the money I offered to you in exchange for the car just as it reduces the value of the money you received in exchange for the car. This perfectly cancels out.

For example, say I have a piece of gold that will be worth $50 more tomorrow. We both know this, and it affects the way we value the gold equally. To whatever extent it makes me want to hold onto the gold more (to gain that future value) it precisely equally makes you want to get the gold from me (so you can gain that future value). Presumably, we both equally value a $50 gain from today to tomorrow, so it should not discourage the transaction -- you want to buy it from me as much as I want to keep it, so we should agree on a fair price for it.

Or, for inflation, say I have a piece of gold that will be worth $50 less tomorrow. I will be more willing to part with that gold because I don't want to sustain that loss. But you will be precisely equally less willing to accept the gold since you don't want to sustain that loss. This perfectly cancels out.

Or, to view it one last way, say the government was about to impose a $100 one-time tax on cars such that whoever owned the car had to pay a $100 tax on a particular day. (This is precisely analogous to a currency deflating -- the value goes up in the future after the tax is paid.) This affects the buyer and seller of the car equally -- they each value the car $100 less before the tax is paid than after. So it won't discourage trading the car, it will just change the price.

That doesn't make any difference. (Unless you want to argue that unpredictable inflation/deflation creates friction. I agree, it does. But predictable inflation doesn't, nor does predictable deflation.)

Cooling is a *massive* problem in space. The two most effective ways of getting rid of heat, convection and conduction, are essentially impossible in space.

Just remember, if you extend $5 in trust to someone, they can wind up owing you $5. If you don't have a settlement agreement with them, that could mean that $5 you intended to be able to spend or cash out is now a worthless IOU. Trust in Ripple is a powerful thing.

It's pointless to use the community credit aspect. But I don't think community credit is going to be a big deal for a long time. I'd love to be wrong about that, of course. I think community credit is an awesome idea.

Bitcoin had, and to some extent still has, much the same problem. What can you do with the bitcoin network? Well, you can send bitcoins to people. But unless you know people who want them or have them, that doesn't help you much.

The trick is to find ways to drive adoption in the absence of large amounts of existing adoption. That is a challenge. We have a few strategies to drive adoption, but the main one is to give away XRP and offer people a free alternative to existing payments systems.

This is very unlikely to happen though.

First, if people don't expect this to happen, then there's a good chance it might not happen. That means you're taking a risk by holding.

If it's a nearly sure thing, then people will expect it to happen, and then they'll bid the price up sooner. If everyone expected gasoline to be $50/gallon in a year, few people would sell it at $4/gallon today. They'd just wait until the price rose pretty close to that $50 right now.

The less you have, the more likely you are to lose everything. However, if you lose everything, you lose less. There's no such thing as a free lunch.

This is a myth. Do inflationary currencies could cause people to hoard commodities? Does a gas station refuse to sell me gas today because he hopes to sell it to me for more tomorrow?

Say I'm considering buying a car and you're considering selling a car. Regardless of the properties of the currency, inflating or deflating, stable or risky, since they affect you and I equally, I should consider the car worth more units of that currency than you do. So we would trade some amount of currency for the car. The properties of the currency might affect the amount of currency we exchange for the car -- it must be less than the car is worth to me and more than it's worth to you -- but it can't close the gap that incentivizes us to perform the transaction.

How do you hoard currency? Well, first you have to get the currency, which means you have to produce something of value and trade it for the currency. And then, well, you do nothing. So hoarding is production and mutually beneficial trade and that's it. It's not a bad thing at all.

Yes. It's an outline.

I'm not sure I follow you. If you want more details, I can provide them. The basic idea is very simple -- a node looks at how long the consensus process has in progress compares to how long the previous consensus round took and adjusts the threshold for a yes vote up from 50% based on that time period.

It's a summary description of a lot of things, for example, no votes on transactions are implicit, you just don't vote yes on them. And, as I mentioned above, nodes increase the number of nodes they require to vote yes to keep their own vote at yes oevr time.

Actually, that's still being adjusted. The current algorithm is as follows:

1) Until 50% of the time the previous ledger's consensus took has passed, 50%.

3) From 50%-85% of the time the previous ledger's consensus took, 65%.

4) From 85%-200%, 70%.

5) From 200% on, 95%.

That is, initially, if 50% of your weighted trust list (including yourself, if you believe you are synchronized) votes "yes" on a transaction, you vote yes on it. Once 50% of the time the previous consensus process took has passed, this goes up to 65%.

A two second minimum is enforced on a consensus round to ensure that well connected nodes have enough time to get an initial proposal in. In addition, nodes won't let a consensus close significantly more quickly than the previous round, for the same reason.

This algorithm actually is about to be adjusted. It has a slight defect  -- the first round of dispute resolution could occur after 85% of the time the previous round took has passed, resulting in transactions getting excluded without reason. Though harmless, this effect wasn't intended. Most likely, it will instead slide gradually up rather than in steps.

There is no harm in conflicting transactions both getting voted in -- a deterministic algorithm ensures only one of them will actually get applied and nodes will agree on which. The same applies if two conflicting transactions each bump each other out -- a deterministic algorithm determines which one all honest nodes will vote yes on in the next round.

Then one node will raise the agreement rate and the other won't. It doesn't particularly matter. The ratcheting up of the agreement rate is only to keep the rate from "puttering" around 50%. If we just used strict majority, and the starting position was about half the nodes saying yes and half no (say because a transaction was introduced just as the ledger closed), you could stall around 50% for a long time, some nodes seeing say 53% and some 46%. To prevent this, nodes have an internal bias that increases over time towards excluding a transaction. This prevents the long stall.

Essentially, the entire system has a huge bias towards excluding a transaction. So long as a transaction remains valid, every honest node that saw it before a consensus window starts will try to include it in that consensus window. So unless the network is heavily overloaded or most nodes trust mostly dishonest nodes, the transaction will get in during  the next consensus window anyway.

This is the key trick to the way our system works. If a transaction should unambiguously no questions asked get in, then every honest node will vote yes on it. If it shouldn't unambiguously no questions asked get in, then nobody particularly cares whether it gets in or not, and not letting it in is perfectly fine. If enough nodes disagree about a transaction for it to stall the consensus process, then honest nodes just switch to no. They value consensus over getting in a transaction that lots of trusted nodes think doesn't belong.

Any node can introduce into its consensus set a transaction to raise or lower the transaction fee. I think we have a rule that only certain ledgers (like one every 256) can have a fee change transaction in them. This is to prevent needless momentary disagreement on every ledger while some nodes want one fee and some another. A fee change transaction either gets voted into the consensus set or it doesn't. If it gets voted in, it is applied and the fees change from that point on.

The current server just votes no on all transaction fee changes. We plan to add a configuration element to set what you think the fees should be and then your server will introduce and vote yes on transactions to change the fee to the fee you set.

We also have a mechanism, I forget whether it's implemented for fee changes specifically, where a node can introduce into specific validations what it thinks the fee should be. This also is done on specific "flag" ledgers. So on flag ledger X, you can put in your validation that you think the fee should be Y. Then on ledger X+2, everyone looks at the validations for the flag ledger to see if there's a super-majority for fee changes. This also helps to void a needless momentary disagreement and it allows nodes to use a more sophisticated algorithm to decide what fee to propose Say the fee is 10, and you think it should be 12, and half your weighted trust wants 11 and half wants 12, you might want to vote yes on 11.

Feel free to ask any specific questions. I thought I already pointed you to where the consensus process is explained in the wiki.

It's basically this:

1) Nodes announce the hash of the last closed ledger. To keep things simple, I'll assume we start from a consensus.

2) Nodes propose the hash of the tree of transactions they think should be applied to the ledger in this consensus window.

3) Nodes acquire the transactions other nodes have proposed.

4) Nodes form disputed transaction entries for transactions so long as at least one node they trust included that transaction and one didn't.

5) Nodes avalanche to a consensus on each disputed transaction by going with the majority weighted based on their trust.

6) If avalanche stalls, the agreement rate requires to get a transaction into the consensus set is raised.

7) As nodes detect that the nodes they trust have reached a consensus, they apply the consensus transaction set and publish a validation of the next ledger.

8 ) Validations push other nodes towards consensus.

9) Nodes acquire sufficient validations from other nodes they trust of the new ledger and consider that the next accepted ledger.

10) If any new transactions occurred during the consensus process or any valid transactions didn't get in, a new consensus process starts immediately.

This trust is just trust not to collude. See the wiki page on consensus.

The main reason it works is:

1) Every honest node wants a consensus. They will wait as long as it takes in order to get one. We have no fixed amount of time in which a consensus must be reached.

2) There is no moving target during a consensus window. With respect to establishing that consensus, the world is frozen. There is a fixed amount of information to be known about the state, and more information is always gathered by nodes. They don't forget anything. The ratcheting up of the agreement level required ensures a consensus will eventually be reached.

3) Dishonest nodes cannot stop transactions from propagating to the vast majority of honest nodes. A node would have to have every single one of its connections to a dishonest node. (And we imagine 'core' nodes agreeing to directly connect to each other as a safety.)

4) So long as a transaction can be applied to the ledger and the vast majority of nodes see it before the consensus window, there's nothing dishonest nodes can do to stop honest nodes from including it. (Nodes will extend the consensus window if they aren't getting votes or acquiring transaction sets from trusted nodes that have voted.)

5) If a transaction does not get into a consensus set, but is valid, every honest node that has seen that transaction will vote to include it in the next consensus set.

6) No honest node particularly cares what's in the consensus set, provided it includes transactions that were seen well before the consensus window started. There is no way a dishonest party could get something into the transaction set that shouldn't be there and have that cause any harm. Invalid transactions will have no effect, even if they get in the consensus set.

I'd be happy to answer any further questions you have.