That's really up to them. I would say pretty much the only criterion is that transaction fees not be so high that they are a barrier to use and, ideally, not so low that they frequently need to be raised to control spam.

You don't need to try to figure out if specific transactions are spammy or not. You just have to look at whether the total volume of transactions is within what the system can handle and also whether the cost of a transaction isn't unreasonably low when compared to the actual costs associated with processing a transaction.

If the fee is so high that transactions are discouraged that the system could handle, it should be changed. If the fee is so low that the network is consistently overloaded and has to raise the fee dynamically, it should be changed.

Transaction spam is not like email spam. It doesn't annoy human beings directly. But it does cost bandwidth and reduce the remaining capacity of the network. The criteria is basically to make sure that transactions that cost more money to process (in terms of bandwidth and storage) than they are worth are discouraged without having to resort to dynamic changes in the transaction fee (because that makes fee and transaction clearing times less predictable).

Posting your secret is not a good idea.

50 billion XRP will be given away by Opencoin. But it still doesn't matter. So long as there are enough XRP in circulation to perform transactions, XRP still won't limit the ability of people to perform transactions. Over a quadrillion drops have already been given away, and consensus can change the base transaction fee to less than a drop.

The primary criterion will be what they believe the transaction fee should be. The secondary criterion will be what they believe they can get a consensus on.

I believe I explained the mechanism in more detail in another thread, but here's a summary:

1) Validators add to specific validations an indicator of what they think the transaction fee should be.

2) Validators look at other validations to see whether there's a sufficient consensus for moving the transaction fee up or down.

3) Validators then add pseudo-transactions to change the fee.

4) If a pseudo-transaction gets voted into the consensus transaction set, fees change as of the next ledger.

A similar mechanism is used to make logic changes, except nodes won't themselves vote yes on a change unless they see it has a supermajority or if they are specifically configured to treat the change is urgent.

There is no specific check for spammy transactions. If it has the correct fee, it will be processed. If the network is overloaded, slow nodes will bow out of the consensus process and the transaction fee will rise to maintain stability.

I have to admit that this is a concern that never occurred to me. But it seems implausible in the extreme. There are a hundred billion XRP, or a hundred quadrillion drops. Let's say 1/10th of a penny per transaction is small enough that nobody need be concerned about it being a limiting factor. For one drop to be worth 1/10th of a penny, the total value of all XRP would have to be one trillion dollars.

If that ever did happen though, the divisibility of XRP could be changed by consensus. Alternatively, we could use a scheme where you prepay for a number of transactions and then can perform transactions without a fee until the account's "transaction credits" drop to zero. The number of transaction credits you got for one drop could be adjusted by consensus.

It did in fact clear, in ledger 288152. For some reason, servers don't seem to be able to get from the transaction to the ledger in which it cleared. I'll try to track down what's causing this bug.

Update: I found the cause and should have a fix shortly. It actually would have fixed itself eventually. While the underlying database is correct, the cached version of the transaction didn't have the reference to the ledger in it.

Update: A fix for this bug has now been pushed.

There is no known mechanism for transacting Bitcoins off the blockchain that doesn't itself require a central authority (to hold the signing keys that would release the bitcoins). You wind up with horrible solutions like each Ripple transaction requiring a Bitcoin transaction. You also have the problem of whether you destroy the bitcoins or pay them to someone. If you pay them to someone who is not a central authority, the scheme can be rigged by someone who puts themselves on both sides.

As was discussed in several of the other Ripple threads, none of those approaches actually work. But even if they did, they would still be inferior solutions because they wouldn't allow anyone to give away enough to allow a large number of people to perform millions of transactions. That would drastically decrease the chances Ripple would ever be a viable payment platform.

Can you clarify what you mean by this? I'm genuinely puzzled.

Yeah, sorry. My crystal ball isn't any clearer than yours anyway. I don't pretend to be able to predict what will happen.

If you want to redeem those IOUs through bitcoin-central, you can just go through bitcoin-central's withdraw process. The IOUs will be exchanged during the payment process.

Otherwise, you should first drop the credit you extend to the issuer whose IOUs you want to get rid of to signal that you want to get rid of those IOUs. Otherwise, you may just get them back immediately. This will also hint to other people that you prefer bitcoin-central IOUs to bitstamp IOUs. Other people who need to go in the other direction will then preferentially use you, giving both of you the IOUs you prefer (this isn't fully implemented on the network yet but should be in the next week or so). That way, they pay some of the fees.

To actually force the IOUs to change without making a payment to someone else, you'd need to either take an offer with the same currency on both sides or create a circular payment path through someone else that pushes IOUs back to you. (Or create a payment transaction that does some combination of these.) I don't believe either of these are supported in the client yet.

As soon as the network is distributed, changes can only be made by consensus. By intentional design, logic changes are difficult to do and require establishing and maintaining a consensus on the change. You wouldn't want someone quickly pushing through a change that, for example, allowed issuers to delete IOUs!

Right now, Opencoin is acting as a central authority and running the network. This makes it much easier to fix problems and make changes quickly. We're fixing issues on a daily basis now and slowing that pace would mean a much longer time before Ripple is a decentralized payment system that people can truly rely upon.

Not any time soon. That's why we're promoting Ripple as a payment network with gateways rather than as a community credit network. I personally believe that community credit is Ripple's long-term killer app and that it will change the way people think about money. So this will always be there and maybe one day it will really catch on. Social money may take social changes, just like social media did. Those changes happened pretty fast, so maybe these will too. It will take better tools to make managing credit more user friendly. We hope to get there, but we aren't relying on it happening soon. The bigger Ripple becomes, the higher the chances this will happen.

Yes, however, we've run into some technical problems designing a usable and safe namespace scheme. The fundamental problem is not having a central authority that approves names but also not having the first person to register names like eBay and Amazon being able to hold them hostage.

The best solution we could come up with is this:

1) Anyone can create a namespace.

2) The client can use any namespace.

3) Opencoin will create a namespace which the client uses by default.

4) Namespaces can be closed or open. They start closed. A namespace's owner can open a namespace but not close it.

5) Opencoin's namespace will be closed for a year or so. We'll come up with some fair scheme to register names. (Yuck.)

6) After a year, we'll open our namespace and it will be first come, first served.

The problem is that this is kind of fake decentralization. If someone tries to create a competing namespace, payments may go to the wrong person. So as a practical matter, we'll run the namespace, and we don't want to do that. We don't want to be Ripple's IANA.

We have a hard rule that we won't implement something until we find a good way to decentralize it. We're not there yet on friendly names.

We do have a domain-based naming scheme because that can be decentralized. Domains can vouch for their ownership of particular account records. You retrieve a domain's configuration file using SSL.

For example, this is bitstamp's main account:


Notice the "Domain" field? That's hex for "bitstamp.net". If you retrieve https://bistamp.net/ripple.txt, you get:


This establishes a reliable proof that the domain belongs to the "bitstamp.net" domain.

"If I tell the system that I don't trust bitstamp to exchange my BTC IOUs for real Bitcoins, should Ripple automatically trust bistamp to exchange my BTC IOUs for real Bitcoins?"

Of course not. If you don't trust them, the last thing you want to do is destroy the IOUs you hold and trust them to actually send you the Bitcoins since that is exactly what you just said you didn't trust them to do. You can use those IOUs to make Ripple payments and exchange for other IOUs and nothing Bitstamp can do can stop you. You can let other people take those IOUs from you and in return give you IOUs from issuers you do trust. If you don't trust them to redeem them, that's what you want to do with them.

If you do still trust them to redeem the IOUs and are lowering the trust because you don't want to acquire any more IOUs (maybe you're switching gateways) or fear that they'll stop redeeming in the future even though you trust them now, you can follow up by withdrawing the IOUs using the gateway's normal interface.

No, it's been 200 for awhile. But you need an additional 50 XRP for each trust line or offer you want to keep open. So the thinking is 200 for the account reserve, 50 to create at least one trust line, and then some XRP for transactions. Really 251 would do.

The internal validator network was intact and functioning as was the public-facing payment network systems. The web site was down due to some problem at the provider. I don't know yet whether it was a denial of service attack or a technical problem, but last I heard they suspected it was a technical problem.

We're currently keeping the number of site running servers and providing the client small so that we can easily fix bugs and make improvements that require coordinated changes to both the client and the server. I'm hopeful that will die down soon and we can move on to making the network more distributed.

You won't be able to return them. Creating an account causes 200 XRP to be held as a reserve. The reserve can only be used to pay transaction fees. An account takes permanent ledger space.

The client asks the server what's possible, the client chooses a source currency and a subset of those lines to use, and then the transaction itself uses whichever lines from that subset cost the least. Currently, the client just does what the server suggests.

That's correct. That indicates that you don't want those IOUs anymore. You can't acquire any more of them (unless you buy them through an offer) and that signals to people that you want to get rid of them.

I can update that one manually from time to time. I'll try to see about an automated way to get the latest ledger. It's not really intended to be practical to get the ledger by any method other than running a server (which efficiently synchronizes the differences between ledgers), but while it still is practical, I'll do what I can to make it possible. The current ledger is about 2.5MB with 3,146 leaf nodes that break down like this:

1,172 accounts
807 trust lines
792 directories (used to find order books and trust lines)
369 offers
6 historical records of past ledgers

Theoretically the same IOUs could be issued using colored Bitcoins, but then you're cramming a round peg into a square hole. Because Ripple is designed to do this, it has features that makes this not just possible but efficient. Colored coins are good for smart property, but I don't see how they get you things like payment paths and distributed exchanges.

The network just treats a currency as an opaque 160-bit number. A portion of that namespace is reserved for three-letter currency codes. The network itself has no list of valid codes, so if you want to use "XBL" for barrels of crude, you can. The client has a list of known currencies, but anyone can modify that list and we can add configurable currencies to store in the wallet if there's demand.

On our planned feature list is fully custom currencies. A custom currency would be created by someone and would have an entry in the ledger. Its currency code would be a hash that would allow the client to find its specification. Custom currencies could be associated with a particular web site and have custom display rules and so on. The feature set is not fully fleshed out yet as the only real use case we have to far as demurrage.

If you're going to sell them for bitstamp/BTC, I'd suggest you open an account at Bitstamp and extend trust to them. Otherwise, you can't withdraw them.

Once you have bitstamp/BTC in Ripple, you would select Ripple deposit from Bitstamp's web site. (Because you are depositing bitcoins into your Bitstamp account.) Once you have the balance off the Ripple network and in your Bitstamp account, you can withdraw it from your Bitstamp account as actual Bitcoins.

So the steps are:

1) Have bitstamp/BTC on the Ripple network.

2) Use Bistamp's web site to deposit these into your Bitstamp account.

3) Withdraw these BTC from your Bitstamp account into a Bitcoin account.

You wouldn't really be an exchange in that case because the exchange itself is not supposed to be a party to any actual exchange. I would just caution you that if you plan to do that, you will have to be prepared to deal with fraud. And the higher your rates, the worse your fraud problem will be.