From Ripple Wiki
(Redirected from Distributed exchange)
Jump to: navigation, search




What happens if someone steals all the founders' XRP?

XRP will still be used to pay transaction fees, its critical network function.


Can you spend without a complete ledger?

Yes. You only need the current sequence number of your account.

Can the same wallet be used simultaneously on different computers?

Yes. However, attempts to overspend will fail.

If people can use dollars all the time via Ripple, how does XRP fit in?

To prevent spamming, transactions require a small transaction fee paid in ripples.

How long before a transaction is considered final?

In ordinary circumstances, a few seconds.

In extraordinary circumstances, this may be as long as several minutes after connectivity is restored.

The client will note when a transaction occurs under extraordinary circumstances. For small transactions and trusted parties, there is no need to wait for connectivity to be restored.

How can a transaction be verified?

The sender specifies a payment address in a signed message. Every transaction has a hash which can be used to look it up via a node with sufficient ledger history. The ledger can then verify that the transaction meets the payment terms.

What would happen to Ripple if Ripple Labs disappears?

The Ripple network would then operate independently of Ripple Labs. Ripple Labs develops and promotes the network, but does not control the Ripple network.

Is there a natural economic force preventing a network split?

For any such split to have a chance at persisting, both halves would have to support interoperability. There is a greater incentive for a federated network that benefits all participants. This is analogous to the reason gmail doesn't make their mail protocol incompatible with all other mail protocols. Failed network Forks are documented on this wiki.

Is Ripple open source?

The rippled server is committed to staying open source, but Ripple Labs reserves the right to build proprietary solutions if and when they benefit the network.

Server source code:

How does Ripple handle privacy?

Anonymity is not a design goal of Ripple, but the network should provide adequate privacy for most people.

  1. Like Bitcoin:
    • if people don't tell anyone an address is theirs, there is no personally identifiable information.
    • if you send your funds to another address you control, you need not claim ownership.
  2. Proxy payments:
    • Accounts can be set to have their payments sent to a gateway. Payments sent this way are not traceable unless either the sender, the receiver, or the gateway reveal the transactions. This allows people to mask their total payments and disassociate their spending from the general public, while law enforcement will be able to subpoena the gateway if needed.

Who will run validating nodes?

Heavy network users may want to run their own servers to track the network. Server operators generally do not have any obligation to provide others with access to the Ripple Network.

If each heavy network user does their part in sustaining the network, then other server operators who also want a fast path into the network will exchange information with them, for mutual benefit.

Running a validating node does not require running significantly more resources than running a server that tracks the network. The Ripple protocol is designed so that anyone with a reputation who needs to track the network will be able to also run a validating node at near-zero additional cost or effort.

Finally, anyone who wants to support a network in which they have a stake can run a validating node. Validators vote on changing the network rules, fees, reserves, new features, and possibly other future network mandates.

For reference, the following parties are likely candidates for running validators.

  • Anyone whose business relies on the network:
    • Gateways
    • Merchants
    • Arbitragers
    • Day traders
  • Anyone who wants to support currency choice:
    • Digital rights groups
    • Libertarian groups
    • Individuals
  • Anyone who wants to support the underbanked or provide a public service:
    • Organizations
    • Universities
    • Anyone who provides hosting services for open source projects

Are validation servers rewarded?

Ripple Labs may sponsor the operation of validators in some circumstances. However, anyone interested in the success of the network can run a validator. The cost of running a validator on top of an already running rippled server is trivial.

How do people with no XRP pay for transactions?

A person without XRP cannot pay for transactions. They must have someone send at least the account reserve XRP to their account for it to be created. After their account has been created, they may begin creating transactions.

Can I change my secret key?

No. The secret key may not be changed. If your secret key has been compromised you should:

  1. Create a new account in a new wallet.
  2. Transfer your funds to your new account.
  3. Set all your credit limits to zero.
  4. Lock your wallet.
  5. Inform your creditors of your new account.

What are the impacts of having a bad UNL list?

To have a bad UNL list, you must intentionally choose to do so.

If the majority of the validators on your UNL decided to defraud you, they could convince you that they had made a payment to your account, when they had not. In which case, you might erroneously provide a payment in return. For example, you might send a real payment in return in which case you would have lost the value of your payment.

Technical FAQ

What is required for a double spend to happen?

A "double spend" occurs when someone relies on the result of a transaction and that transaction is subsequently invalidated. Double spends are a concern because a merchant may irreversibly deliver a product expecting payment from a transaction and may suffer a loss if they subsequently lose the funds they relied on that transaction to deliver. Ripple provides specific confirmation of transactions that are irreversible. If this indication were to be provided and the funds later be revoked or reversed, that would consitute a double spend.

One possible cause of a double spend would be a bug. As the Ripple network increases in maturity over time, this possibility becomes less likely due to continuous testing, additional auditing of the source code, and bug fixes.

A double spend could also occur when a transaction passes the server's confirmation logic but is subsequently invalidated. The server's transaction confirmation logic confirms transactions when they appear in ledgers that pass its ledger confirmation logic, so a double spend would require convincing a server to accept, as fully confirmed, a ledger that subsequently disappears from the public ledger chain.

The logic to accept a ledger as fully-confirmed has two steps. First, the ledger must arise as the result of the network's consensus process, that is, the majority of the operating, trusted validators on the network must agree on that ledger. Second, a majority of the validators on that particular server's trust list must certify that they saw a super-majority of the validators that they trust observe that same consensus process and agree on that ledger.

Double spends are prevented both at the network level and at the individual server level. Individual servers protect themselves against double spends by selecting validators which are unlikely to collude. As the Ripple network grows, the network as a whole will protect itself from double spends by maintaining a diverse set of validators operated by notable and reputable individuals, organizations, and business .

If one were the victim of a double spend, everyone would have cryptographic proof that this had happened and would know which validators, and which operators, had betrayed the trust extended to them. Even now, with few validators, the Ripple network is secure because all the validators have a collective interest in the Ripple network succeeding, and cryptographic proof of their attempted betrayal would be suicide.

How does the distributed exchange work?

Distributed Exchange

At its core, Ripple is a distributed database secured by cryptography. The database is used to store the ledger which contains the current state of everyone's balances and trust limits. The ledger can also store other entries.

If someone holds 10 BTC and they are willing to sell it for $130 USD, they can place an offer entry in the ledger stating so. Then anyone who wants to can take them up on the offer. The Ripple network moderates the transactions and makes it happen.

Why have a sequence number per address?

It is the simplest way to ensure that a transaction cannot be applied more than once and to easily reject old transactions replayed to the network. Once an account has passed the sequence number for a transaction, that transaction cannot be applied to that ledger or any subsequent ledger.

How are invalid spends treated?

  • Spends over balance on a transaction are ignored or delayed.
  • Spends out of sequences are delayed.

Can Ripple do blinded cash like open transactions?

  • Blinded cash can be transferred and redeemed without the issuer knowing who has the cash.
  • http://en.wikipedia.org/wiki/Blind_signature
  • In open transactions, blinding is used so that the issuer does not know who the intermediaries are for currency that is passed among a group of people.
    • The issuer take currency, verifies it is valid and then issue a new instrument that can only be redeemed with a private key unknown to the issuer.
    • Ripple and Bitcoin have this functionality built in to an extent.
      • The coins can repackage currency by creating a new address.
      • What open transactions does which is different is no intermediary transactions are stored.
      • That is with open transactions, without collusion, there is no record of transactions to follow.
    • Ripple operates the ledger publicly, so anyone can create a record. To be like open transactions, ripple would have to have an anonymizing server and a signing authority.
      • Ripple has no issuers/signing authority for ripple, it has global consensus which is implied from local consensus.
      • Ripple has no anonymizing servers.
      • Ripple has facilities for issuers to audit anonymizing servers.
      • Introduction of a trusted authority defeats ripple's decentralization goals.

Can you encrypt all connections?

Short answer: Yes.

A longer answer: http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html

Can a Ripple validator block a user?

Ripple validating nodes can choose which transactions to forward and accept. They can vote no to any transactions, but they must process transactions agreed to by the consensus of the network.

If validators block specific transactions without justification, this will be obvious from the proposals they send. If people believe this action is unjustified, they can present those signed proposals along with other signed proposals for other validators to prove the behavior. That is, a validator cannot do this secretly. If others disagree with this behavior, they can, and should, stop trusting this validator.

Ripple Questions

Why is Ripple not vulnerable to Bitcoin's 51% attack?

Bitcoin relies on the distributed computational power of Bitcoin miners to protect the integrity of the Bitcoin network. Bitcoin is vulnerable to an attack by anyone who can accumulate computational power equivalent to 51% of the Bitcoin network's computational power.

In contrast, Ripple utilizes consensus to protect the integrity of the ripple network. Having excess computational power does not provide any advantage to an attacker. As such, Ripple is immune to attacks based on computational power.

An analogous attack for Ripple would be for someone to control the majority of Ripple validators for each Ripple participant. As each Ripple participant chooses their own validators, they can easily avoid this problem by simply not choosing colluding validators as the majority of their validators.


  • As soon as an attack is discovered, it is easily identified along with who the colluding validators are.
  • If a person discovers that a validator is colluding, they can simply remove that validator from their validator list.
  • The attacker's maximum payoff for a successful attack is temporarily disabling the network.
  • Since the payoff is so minimal and the difficulty is so high for each attack, it is extremely unlikely this scale could be reached.

What are the minimum requirements for compiling and running rippled?

The minimum system configuration for successfully building rippled are:

  • 8 GB RAM
  • 16 GB disk space
  • 1 64-bit CPU

We would recommend an m3.medium instance on Amazon's EC2. rippled will run in environments with only 4 GB of RAM, but aspects of the public ledger caching system will be impacted.

rippled just shut itself down. What happened?

If you look in the debug.log file generated by rippled, you may see errors like this:

2014-Apr-08 02:12:38 Application:FTL Remaining free disk space is less than 512MB
2014-Apr-08 02:12:38 Application:NFO Received shutdown request

This means that rippled is out of disk space for storing a copy of the public ledger and shut itself down to preserve the integrity of the rest of the system. You will either have to delete the local copy of the public ledger and let the node re-sync, or you'll have to add more disk space to hold the ledger (which is fairly easy to accomplish with little downtime if you used LVM). At the rate at which the public ledger is growing, you should probably plan on a minimum of 16 GB of disk space to store the ledger.

However, if you look at the amount of disk space free (with the command df -h, for example), you will see that the amount of disk space used is actually less than 100% of maximum. This is a feature of the EXT? Linux file systems which is more fully discussed here.

Should I run rippled as root?

Short answer: NO.

Longer answer: You should not. In the unlikely event that there is a remotely exploitable vulnerability in rippled, running it as root means that there is the potential for system corruption, i.e., the attacker would be able to modify arbitrary parts of the system because rippled would be running with root privileges. Running rippled as a service account (i.e. without elevated or root privileges) minimizes the potential harm that the attacker could do.

To set up a service account for rippled, run the command sudo useradd -U -m -r -G ssl-cert -s /dev/null rippled

What the command line switches mean:

  • -U - Create a matching group called 'rippled' at the same time.
  • -m - Create the user's home directory if it does not exist.
  • -r - Make the new user a system account, not a user account. This means that a home directory will not be created, the UID and GID will not be 0 (but will be less than the first user account's).
  • -G ssl-cert - Add the rippled service account to the group "ssl-cert" so that it can access the SSL certificate pair.
  • -s /dev/null - Make the service account's default shell /dev/null, or not shell.

In our Debian-style initscript, we start rippled under the context of the service account like this:

start-stop-daemon --start --quiet --background --make-pidfile /var/run/rippled.pid --exec /usr/local/sbin/rippled --chuid rippled --group rippled -- --net --conf /etc/ripple/rippled.cfg

You can do the same thing manually with sudo:

sudo -u rippled -g rippled -- /usr/local/sbin/rippled --net --conf /etc/ripple/rippled.cfg

Additionally, everything but the database directories configured in rippled.cfg should be owned by root. This is to mitigate the risk of an attacker using a remote exploit to overwrite files or reconfigure rippled. The attacker would, in theory, be able to read files but would be prevented from altering them.

What are some good places to put rippled-related files?

Internally, we configure rippled to put its resources in UNIX-like places:

  • The config file is /etc/ripple/rippled.cfg
  • The database files are in /var/lib/rippled/db in the subdirectory rocksdb/

My Ripple log files are huge! What's going on?

By default, rippled is configured to generate debugging logs, which are extremely verbose and require significant amounts of I/O and CPU time to write to disk. While this is handy for debugging rippled it is often harmful in production. The log levels which rippled is capable of are:

  • trace
  • debug (default)
  • info
  • warning (preferred)
  • error
  • fatal

The logging configuration can be changed without restarting rippled via the JSON-RPC interface, like this: rippled --conf /etc/ripple/rippled.cfg log_level [log level]

The configuration change will take place immediately. It can also be made semi-permanent by editing the rippled.cfg configuration file and adding text similar to the following near the end:

{ "command" : "log_level", "severity" : "[log level]" }

In both cases, the value of [log level] is from the short list above.

It is safe to stop rippled, delete the log file, and restart it.

Bitcoin Questions

What is the impact of a Bitcoin 51% attack

See: Bitcoin 51PercentAttack

  • Exactly what someone would need to do to execute a successful botcoin 51% attack?
  • How much it would cost?
  • How long would it take?
  • Who could do it?