The server is not open source yet. Once the server is open source, we'll have to obtain a consensus on every feature change that affects what transactions are valid or what effects they have, just like Bitcoin does. I used to say we sometimes make those kinds of changes three times a day. We're probably down to once a week at most now.

Only if you want to use Ripple as a platform for social/community credit.

If you choose to trust someone and they default, then you lose whatever money you trusted them to borrow from you or hold for you. We're not promoting Ripple as a social/community credit platform right now but rather as a payment and exchange system. (Though I have high hopes for it in the future.)

Yeah, my numbers are off by a factor of 79,228,162,514,264,337,593,543,950,336. Finding another key with the same hash is sufficient. (Third time I've made that mistake.)

First, add TTBit to your contacts. Then under advanced/trust, allow TTBit to hold DYMs for you up to some amount.

You can now just make a payment to yourself of, say, 2 DYMs. You will be given the option to pay with any currency you hold enough of that has sufficient liquidity. (You actually have to paste in your own Ripple address as the destination.)

To place or take an offer to buy DYMs directly, go to the trading section and choose the two currencies the offer will be between. You want DYM/XRP (you can type it in, you don't have to use the pulldown). When it asks for the DYM issuer, enter TTBit and select it. This doesn't mean you want to buy from TTBit, it means you want to buy TTBits DYMs from someone. You can then see the order book (by clicking 'Order Book' at the bottom).

To buy DYMs click 'Buy DYM' if it's not already selected. Then fill in any two of the amount of DYMs to buy, how many XRP to pay for each one, or the total XRP value. Click 'Place Order'. If your offer crosses an existing offer or offers in the other direction, it will fill (or partially fill) immediately. You can always cancel the unfilled portion of the order by clicking 'My Orders' and hitting the cancel button.

For some reason right now, the direct liquidity of XRP to DYM is not great. You'll probably do better paying yourself DYMs.

bc
http://www.gnu.org/software/bc/

It's about 3,513,612,269,993,879,528,303,320,959,297,632,275,254,396,583,673,016,120,886,766 times harder to crack an address than to find a nonce that mines a block. Given that mining a block yields 25 bitcoins and cracking an address yields at most 21,000,000 that means that even if you crack the address that holds every single bitcoin that will ever exist, it's still 4,182,871,749,992,713,724,170,620,189,640,038,422,921,900,694,848,828,715 times worse than finding a nonce.

Yes, you can. You can pick a particular currency pair and place or take offers.

You can also create a DYM pathway and then just make a payment to yourself of, say, some number of DYMs and click the 'XRP' payment button. That can take from combinations of exchanges and pathways to get a better deal, if there is one.

It looks like someone is intentionally maintaining liquidity between TTBit's DYMs and USD at Bitstamp. It's possible that it's TTBit himself because he understands that the less you have to trust him to use his service, the more people will use it. If you want to cash out DYMs and don't want to deal with TTBit, you can cash out USD.

Presumably, if TTBit were to go out of business or have all his dimes stolen, this exchange path would rapidly dry up. But so long as his business is healthy, there is likely to be liquidity in the Ripple network for his balances. You don't have to worry much about TTBit targeting you specifically except for amounts in the process of being redeemed. You do have to worry about the health of his business as a whole, but you can judge that at any time just by looking at whether his balances are liquid. Now, they are.

Most likely, to successfully operate a minor gateway, you'll have to make it your business to ensure liquidity to the same currency from a major gateway. So, for example, if you want to be a minor USD gateway, you'll probably try to have a 1-to-1 (or .995 to 1 or whatever) offer available to trade your balances for balances at, say, Bitstamp. That means you'll have to keep cash on deposit at a gateway to "back" your balances.

Over time, as your reliability is proven, people may not bother taking you up on that offer very much. If you provide your offer at 0.995 to 1, someone else may provide an offer at 0.997 to 1 and make some money on the arbitrage.

Correct. The server scans the balances the user holds and the pathways and exchanges in the Ripple network and computes the cheapest paths for each currency the user holds. (Heuristically, it is not perfect.) When the transaction is formed, a set of "best discovered paths" is included. When the transaction is executed, funds can go through more than one of the included paths to get the very best exchange offers, even switching exchanges, available at that moment.

Yes. Ripple is like a cross between Bitcoin and conventional banking. We do unfortunately get some of the downsides of fiat currencies and conventional banking. But lots of people do seem to find them useful, so we can't all move forward to the obviously superior crypto-currencies yet.

There are actually several different ways you can see this. One would be to look at exchange rates to some common currency. For example, let's say Bytestash/BTC was trading at 80,000 XRP to the BTC while MeExchange/BTC was trading at 120,000 XRP to the BTC. Assuming both prices are reasonably stable and there's adequate market depth, that indicates that for some reason people are valuing MeExchange/BTC much more than Bytestash/BTC. Of course, there's basically no logical reason for that unless Bytestash is not redeeming BTC reliably.

Another way would be to look at how much a payment costs. Say someone wants 10 BTC and you decide to pay them with Ripple. Say you hold MeExchange/BTC. If the client tells you that you need to pay 14 BTC to make the payment, that means that your "10 BTC" from MeExchange is not actually being valued by the recipient (more precisely, the combination of paths through the network to the recipient) at 10 BTC, indicating that MeExchange is probably not redeeming reliably. (Or that one recipient might have bad paths. But if it happens on many recipients, that points to a problem with your gateway.)

If a gateway wants to stay in business, people will have to be able to use their balances with that gateway to make payments at very, very close to face value. And they'll expect to see exchange rates that reflect the face value of their balances. If not, others will devalue their balances and this will immediately hurt their customers, which they will likely lose.

Nobody wants to give $1,000 to a gateway and get a balance that purports to be "1,000 USD" but won't spend like the cash they traded to get it!

If network connectivity is severed, then the system can't be used reliably, obviously. This is much easier to detect with Ripple than it is with Bitcoin -- you never consider a transaction validated until you see sufficient validations for a ledger that contains it (or is chained from a prior ledger that does), which you can't if the network is severed. With Bitcoin, you'd have to notice that the block discovery rate seemed strangely low, which you can only infer statistically*. With Ripple, you'll notice the absence of validations from all nodes you're disconnected from immediately after the next ledger closes.

You are correct that we can only simulate robustness in the face of attack models that we can think of. Any system is potentially vulnerable to attack models that weren't imagined by its designers. This is another reason we want to get the system completely open and decentralized as quickly as possible. We don't want people to have any reason not to trust the system.

* Until and unless someone implements more clever solutions, I believe some people who accept zero or one confirmation Bitcoin transactions do implement such solutions now.

The Ripple wallet doesn't really hold BTC. It holds the fact that Bitstamp (or whoever) owes you BTC. You have to go through Bitstamp because Bitstamp is holding your BTC. We do plan to integrate gateways of all kinds (including inbound and outbound Bitcoin gateways) into the client. So you'll still be doing the same thing, but you'll be doing it in one step right from the Ripple client.

This has been the complete opposite of my experience, admittedly to my extreme surprise. The majority of the investors I spoke to were more interested in changing the world than making money. I kid you not.

Are computers sketchy because if you put nonsense into them you get nonsense out? So long as you putting nonsense in can't make me get nonsense out, there's no problem.

If I create a USD pathway only to Bitstamp, then Ripple will tell me I have a USD balance if, and only if, I hold USD that is issued by Bitstamp. The beauty of the Ripple system it that it can make payments work seamlessly even among users who choose different currencies and different gateways and only a default by a gateway you chose to trust can harm you.

Sign up with an account at Bitstamp or WeExchange (preferably the one who issued the BTC you hold, if possible) and select Ripple under their deposit options. This will let you deposit Bitcoins into your Bitstamp or WeExchange accounts from Ripple. Once the Bitcoins are in your account with the gateway, you can select Bitcoin under their Withdraw options and this will let you withdraw them to a Bitcoin account.

You need 200 XRP to open an account. Those XRP aren't spent, they're just held on reserve (you can't transfer them) but you can use them to pay transaction fees.

There is an additional 50 XRP you must have on reserve for each object "charged" to your account. This would include offers to exchange currencies and pathways you permit to hold currencies for you. So if you want to have three offers at a time and trade in two currencies on two exchanges, you'd need an additional 350 XRP sitting in your account. These reserves are released when the object is destroyed, so if you cancel one offer and place another, the required reserve doesn't change.

The only time XRP is destroyed is for transaction fees. Currently, the standard transaction fee is 10 drops, or 100,000 transactions to the XRP. There may be more expensive transactions in the future, and the transaction fee will go up if system load increases.

For most people, we expect that 1,000 XRP would fund everything they would probably want to do with their account for many years. I believe you can currently get 1,000 XRP for somewhere around $1 or so. There will be more XRP giveaways too.

Transaction fees are destroyed -- they simply cease to exist. Transaction fees and reserve requirements can be changed by consensus.

I don't think we are. We've been quite clear about what's open now and what are future plans are.

It depends on conditions. Right now, they're averaging about every 20 seconds. It can drop to every 5 if there's continuous transactions. The "idle interval" can change based on network timing accuracy as well. See https://ripple.com/wiki/Continuous_Ledger_Close

There's no conflict. For example, Bitcoin doesn't require you to trust any central authority, but most people either use online wallets (where they trust the wallet operator) or download client software (where they trust the software provider). The important thing is that Bitcoin doesn't *require* them to trust people in this way. They just do so because it's convenient -- making a considered judgment to balance risk and convenience.

All XRP were created when the genesis ledger was created. No further XRP can ever be created. Other currencies are created when a pathway is created with a non-zero limit and then funds are pushed along that patway.


We've simulated precisely that condition. How fast it converges under those conditions depends upon the latency between the nodes. Under most realistic conditions, it can converge within 4 seconds, even with 1,000 nodes. Large numbers of conflicting transaction can increase the time. 5 iterations won't typically take more than 6 seconds. The network will take as long as it takes to reach consensus. There is no particular required time. Nodes that are particularly slow will "bow out" to improve the network's performance. There's a safety to ensure we don't shrink to a small set of "super nodes".

A worst case failure will result in a persistent network split not unlike the hard fork Bitcoin had recently. One difference is that every Ripple node will immediately know that there's a hard split rather than requiring manual intervention to stop processing transactions as Bitcoin did.

The resolution would depend on the cause of the split. If both halves were equally good and the split occurred due to some freak occurrence, a decision of which fork to take would have to be made as it was for Bitcoin. If the cause was malicious, honest people should choose the non-malicious fork, even if it's in the minority somehow.

I'd say such a split is basically inconceivable, but I would have said the same thing for Bitcoin, and it happened. So, yes, it could happen.

Not yet.

There a wiki and I'm happy to answer any questions. https://ripple.com/wiki

The client is. The server will be as soon as it's stable enough.

We are already signing every ledger and publishing every transaction. Every transaction is signed by the account holder. Every change in the ledger (the set of all account states) is justified by a transaction. If we were to cheat in any way, this would be trivially provable. There would be one ledger with the previous data and one with the cheating data, and we would have signed both of them, and there would be no valid transaction justifying the change.

Again, we sign every new ledger, about every 20 seconds. Each ledger also includes hashes of previous ledgers. So say we modified a ledger so that some balances were changed. There would be the ledger before we changed it, signed by us. And there would be the ledger after we changed it, signed by us. And in the ledger would be the tree of transactions. If there was a valid transaction that explained the change, it would be legitimate. If not, that would be trivially demonstrable. We simply *can't* cheat and get away with it.

http://pastebin.com/R7i9DYZj
This is an example of a published transaction, included in a signed ledger. It is signed by the account that generated it. And it includes metadata that shows every node in the ledger it changed and precisely how it changed it. No changes to balances, offers, or the like are ever made without this type of justification. And if such a change ever was made, it could easily be shown beyond doubt.

We designed the system so that people would have good reasons to trust it without needing a central authority to trust.

I don't know what you mean.

By consensus. Here's the simplest explanation:

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.

Essentially, to perform a transaction, you walk into the room and read out the transaction. Every honest person in the room agrees the transaction is valid. They then follow a set of deterministic rules to apply the transaction to the ledger (the state of every account), form the new ledger, and each person in the room signs the hash of the new ledger, which they now agree on. Anyone who tries a double spend will find their transaction won't fit in the ledger because a conflicting transaction already has.

If both transactions appear at about the same time, a deterministic rule decides which one wins.

A transaction is considered validated once it's included in a ledger that has been signed by the majority of people in the room.

People were unable to cancel orders for extended periods of time. That's a pretty serious problem, IMO. Though I agree that a rollback isn't the solution.

There's really no evidence here that this is Mt Gox's fault. Most likely, it's an exploit that takes over control of the browser. If you had a Mt. Gox window open, it can read any information or click any links that you can. The vulnerability is most likely in your JVM or in your browser. (Unless it's an XSS thing, in which case it could be at least partially Mt. Gox's fault, but honestly I think that's less likely.)

Of course, that's not to place any blame on you. Yes, you could have run the browser in a VM you only use for Gox and close it any time you're going to do anything else and sweep your computer for malware before you open the VM and keep the VM encrypted and ....

But then basic stuff would be pretty incredibly hard, wouldn't it?

It's the job of these antiviruses to protect you from malicious stuff like this, and they failed you. Of course, providers of antivirus software take no responsibility for the reliability of their software.

That whole transaction was for 0.25 Bitcoins. 0.08 BTC went o Gox and the rest of them (0.1695 BTC) went back to you (with about three confirmations now).

Sure, with enough thrust you can make a pig fly. But the end result is almost always a lot better if you start out designing something to fly from the beginning.

Say an exchange has to go through three paths each with two hops. Are you suggesting you can form a transaction and get six nodes to sign it in time for the transaction to still be relevant? Or are you suggesting that we freeze all the exchanges to give you enough time to accumulate the necessary signatures? Or do you implement the transaction in phases so that if a later one fails you wind up with an asset you didn't want and have made a partial payment?

Yes, you can make it work. Can you make it work well? Maybe, but it's a heck of a challenge. Will it ever work as well as something designed to do it from the ground up? Not likely, since you start out with strikes against you.