The number of hops is irrelevant. How many people you trust and how reliable they are has nothing to do with how many hops a payment takes.

That's not how trust works in Ripple. The trust line only exists for the instant the payment is made. Otherwise, each extension of trust is independent of every other one.

If you trust B, presumably it's because you entered into an agreement with B such that they have an obligation to settle their debts with you. What interaction they have or don't have with C is none of your business. Either B makes good or they don't. If they don't, then they are betraying your trust. Nothing C, D, E, or F does has anything to do with it.

It's like if I send you a check for $50, you deposit it in your bank, and then your bank goes out of business without paying you. It's not my problem. I only chose to trust *my* bank. Once you take the $50 as payment, how you settle with those you chose to trust is your issue. (When you set trust, you are essentially setting what you are willing to accept as payment.)

Because of issues like this, we're not relying on the community/social credit angle. I think long term it has tremendous potential and may even change the way people think about money, but there are a lot of hurdles keeping us from getting there.

No, don't do that. You'll miss out on great deals like this one: https://bitcointalk.org/index.php?topic=110566

"Note: Please don't mention this market in this thread if you know it already. You are not allowed to sell this information after acquiring it. If you do, I'll just call you a scammer on that market."

As far as I know, it has not been discussed in any kind of detail. We did discuss the downsides of raising the reserve -- people will suddenly find XRP that they expected to be able to transfer would be locked up. Also, large drops in the reserve could disrupt expectations. So I expect we'd argue that the reserve should only be raised if absolutely needed and should only be lowered slowly.

I would expect validators to vote their own personal interests -- which brings up an interesting consequence. You want to trust validators not only that you trust to be well managed and not collude but also that you expect to "vote" on fee and feature changes in ways that make sense to you. Of course, validators cannot vote in secret, so if a validator votes against a widely-desired feature or for an unfavorable fee change, expect that to reduce their trust.

That assumes the base reserve stays at 200 XRP, which it may or may not do. It's established by a consensus of validators weighted by how much other validators trust them. I expect that in the future, this will mainly be merchants, so if they want the fee lower, they can probably push it lower.

To clarify the order book issue, it works like this:

To place an order, it must be at least partially funded. That is, if you are offering something, you must have some of it. The offer need not be fully funded however. You can, for example, offer to buy 100 XRP for 2 BTC even if you only have 1 BTC.

If an offer is discovered to be unfunded (or runs out) while it's being taken, the offer is removed. Otherwise, an unfunded offer stays. Partially funded offers always stay. So my example offer would stay on the books until it ran down to 50 XRP for 1 BTC. At that point, if anyone tried to take from that offer, it would go away.

The server doesn't provide the client the information needed to tell how funded an offer is. The plan is for the server to, when reporting orders, also report how much the offer is funded. The client could then show only the funded portion of the offer.

This makes order books appear deeper, sometimes absurdly deeper, than they really are.

This wasn't at all planned or intended behavior. We just never considered how support for partially-funded offers would affect the order book view. Because this requires both server and client support, it will take awhile.

The ledger is public, I update the downloadable ledger from time to time, so anyone can find particular offers to see if they are funded. If anyone has a particular need for a current ledger, feel free to PM me and I'll update it.
http://goo.gl/GfoZW

Spamming one time won't do anything. It takes hundreds to have any significant effect.

The type of spam we're trying to protect against is meaningless transactions that clog the network and block legitimate transactions. And it doesn't matter what the cost is, so long as it is non-zero. For an attacker to prevent your transaction from getting through, he must pay a higher fee for each of his transactions trying to clog you than you are willing to put behind that one single important transaction. It makes no difference if that's .00001 XRP or 50 XRP.

When the network is overloaded, the transaction fee is "bid up" to accommodate the load. Those with important transactions can just raise the fee they pay. Those with unimportant transactions can just wait it out. It just has to be something with some non-zero value or that an attacker will eventually run out of (or have to pay for).

It's still in a very paranoid mode where if it sees anything suspicious, it takes itself down. The client-facing server took itself down.

It's not difficult to change the scheme from a fee per transaction to a special "fund" transaction that sets a certain number of "prepaid transactions" in your account. You can then perform that number of transactions for no fee. The amount of transaction credits you get per drop could be adjusted by consensus. Similarly, the currency could be made more divisible by consensus.

We wanted to do XRP calculations internally in a 64-bit unsigned with one bit reserved to signal that it was an XRP amount and one bit free as a sign bit. To avoid having to deal with overflows inside operations and simplify the code, we didn't want to use more than 1/16th of the legal range. For human convenience, we wanted the main unit to be divisible into millionths. That set an upper limit of 2^(64-2) / (16 * 10^6) or 288 billion. 100 billion seemed the most human-friendly number within that range.

That makes no difference. The amount of mining is determined by the value of mining. Anything that increases the value of mining would be expected to equally increase the amount of mining. All the additional mining, equal to all the additional value, would be waste. The only reason mining isn't pure waste for coins like Bitcoin is because it is required to secure the currency.

Essentially, you are arguing that it's better to waste and destroy resources than to use them to promote Ripple. You are arguing that it's better to make people do pointless work to "earn" XRP than give them away for free.

It's hugely different. In one case, resources and energy that exist only in finite supply and could have gone to productive uses are wasted. In the other case, there is no waste at all.

I'm making reasoned arguments, not offering opinions. Arguments are valid or invalid regardless of who makes them.

I completely disagree. So long as the supply is limited, XRP can prevent spam, even if they are given away for free. The waste you are advocating is entirely needless. There is simply no need for anyone to ever waste anything to acquire them. You are arguing for huge amounts of wealth to be destroyed and power to be wasted for absolutely no reason whatsoever.

This is exactly what will happen once 50 billion XRP have been given away.

The only real difference between your PoW approach and our giveaway is that yours requires people to waste money and resources on needless PoW computations and ours doesn't. And ours allows giveaways to be used to promote the system and drive adoption and yours doesn't at least, not as much. Your scheme also allows people who put effort into building optimal PoW setups to get larger shares of XRP than ordinary people who don't. Your scheme is easier to implement. As I said, using PoW as a giveaway mechanism is still very much on the table.

If you mean using PoW to submit transactions directly: Whatever PoW algorithm you use, an attacker can set himself up to solve it optimally. Legitimate users are stuck with mobile phones, smart credit cards, or Javascript in browsers with limited PoW capability. An attacker can create as much proof of work as he wants without depleting any finite resource. So you're trying to ration based on something that is available to an attacker in literally infinite supply. Then what do you do? Replace your computer with a faster one?

If you mean using PoW to distribute a currency: Sure, that works. But it's arbitrary, unfair, and wasteful. It makes perfect sense for bitcoin because it's needed to secure the blockchain. It's functionally equivalent to auctioning off the currency as the people willing to invest the most in obtaining it wind up with it, except the money is wasted instead of put to anything remotely resembling good use.

That makes absolutely no sense. Either the scheme is profitable beyond the raw value of the XRP or it's not. If it is, then it makes sense to buy up XRP to do it. If it isn't, then it makes no sense to do it regardless of how you got the XRP.

In the transaction, you specify the source and destination accounts, the destination amount and currency, and the source currency. If you specified the source amount, the transaction would fail if the network state was even slightly different from the state it was in when you formed the transaction. So instead, you specify a maximum amount you are willing to pay to deliver the destination amount. The network computes the minimum amount to make the payment with the paths specified. So long as it is equal to or less than the maximum source amount, the transaction goes through. The amount you pay is the actual amount needed.

So it's not that you transfer a little more, it's that you allow the transaction to transfer a little more should that be necessary.

Someone who holds a large number of XRP can temporarily raise the cost of transactions. But to keep the cost of a transaction over, say, 10 cents, they'd have to be willing to put ten cents worth of XRP behind every transaction that they make. Presumably, the volume of their transactions will exceed the volume of legitimate transactions at that price, otherwise substantially the same thing would happen without them. So they'd be losing more XRP than the total value of all legitimate transactions that might occur. It's hard to imagine how this could possibly be done at a profit.


This has nothing do with XRP distribution. Provided they can be freely exchanged, the same problem would occur with any distribution. How you got your XRP in the first place has no effect on what you can most profitably do with them once you have them. If this attack worked, someone who bought up XRP could perform precisely the same attack with precisely the same effects. If it was profitable, people would be motivated to buy up XRP to attempt this.

I don't think it much matters because you can't easily get a human's attention. Most likely, nobody is going to look at those fields. We've tried to keep the design so that you can't easily compel another person's attention.

If models do arise, I think probably the best solution would simply be for the client not to report it to the user. For example, if someone not on your list of known accounts sends you a microscopic amount of XRP, you probably just don't want to get notified. If we do things like integrated messaging, they'll have anti-spam features built in such as requiring permission first.

We are not really expecting the transaction fee to protect against that kind of spam. It may to some extent do so "accidentally", but that's not what we mean when we say it protects against spam -- we mean pointless transactions aimed at clogging out legitimate transactions.

There is no way to ensure the network is in precisely the same condition when it processes the transaction as it is in when you form the transaction. To prevent transactions from failing unnecessarily, the client generally applies an extra 1% "slush" to ensure the transaction goes through. This could result in a transaction leaving you in debt. I don't think there's currently any way to change this behavior. (You could always transfer 1% less, I suppose.)