The JavaScript client now has code to build a raw binary transaction and sign it locally. Secrets are no longer sent over the wire.

There is documentation on the binary format in the wiki, but it's kind of hard to get a high-level overview from there.

I don't think he was trying to make a legal point or explain how much Coinabul could be forced to pay. I think he was making an equitable point. (The law roughly follows the equitable argument anyway, as it fixes dollar amounts but allows interest rates pegged to inflation, which accomplishes roughly the result of producing a currency-neutral measure.)

Why do you say so? High prices suggest high demand. High demand can evaporate easily, as we've seen several times. This adds currency risk that discourages the use of Bitcoins as a means of exchange. I think it's generally accepted that Bitcoin's long-term success is based on it gaining widespread acceptance as a means of exchange.

High prices indicate greater demand for Bitcoins but that could be either as a store of value, a means of exchange, or for speculation. So greater adoption (which is certainly good for Bitcoin) will lead to higher prices. But higher prices could just indicate more speculation which means more of a risk of a bubble collapsing, people finding it harder to price things in Bitcoins, more risk when holding Bitcoins, and so on.

Stable prices are good for adoptions. Rising prices are an indication of increasing adoption (good) but can also indicate rising speculation (usually bad, depending on whether it's justified by increasing adoption).

I don't understand what you're asking. You don't need Ripple for Bitcoins, just send them with a transaction. The point of Ripple is when you need to send things like dollars or Euros or send dollars to someone who needs to receive Euros.

(If you mean Ripples/XRP, see the many other threads were I've tried to explain why this is the best solution to transaction spam that we could come up with and it adds value to the network in other ways.)

It's just an arbitrary choice as a reasonably-stable measure of value. You could use any stable currency.

Did you have the carrier trace the package? Does the carrier claim they delivered the package to the destination?

Even if this scenario was realistic, what would happen is that as this gradually started to become a problem, two things would happen:

1) Some people would be driven away from Bitcoin because of the high transaction fees. This would reduce the demand for Bitcoins, lowering the price. Thus the problem could, at worst, slow the increase in adoption.

2) Every stakeholder would have an incentive to alleviate the problem. As history has shown, it is likely that a systemic threat to Bitcoin will be dealt with by the stakeholders working together to their mutual benefit. https://bitcointalk.org/index.php?topic=822.0

The system is a feedback loop. It doesn't do one thing, then do another thing, then stop.

So let me get this right, you're arguing that Bitcoin will become so popular that nobody will use it?

I wouldn't really compare them directly as they're aimed at solving different problems. Bitcoin is first and foremost a currency that also has a built in payment system for that currency. Ripple is first and foremost a payment system for all currencies that also has a built in social credit system.

It is just not rational to be this risk averse. This is like not taking an airplane because you're afraid of terrorists. Most businesses currently take credit cards, paying 2% or so for payment processing. That's equivalent to one out of 50 customers not paying you a dime. That's like having your day's receipts stolen from you more than 7 times a year.

Right now, nobody has a stronger incentive in seeing Ripple succeed than OpenCoin does. But we do agree with you about the importance of Ripple being decentralized. That's why we designed the system from the ground up not to require any central authorities to operate. Long term we gain nothing from running or controlling the network. It will take time before Ripple actually *is* decentralized though. If you want to wait and see because you're very risk averse, that's fine. Just make sure your avoiding risk is rationally balanced against the cost of lost opportunities.

We just identified a bug that could cause the tecPATH_PARTIAL case. It could also affect the other cases. I'll add some paths as you describe to my test cases.

You don't have to make a billion dollars overnight to be successful. Long-term real success, changing the world kind of success, is better than making a few bucks quickly, even if the risk of total failure is significantly higher.

Order books will always be used when a change of currency is required since that's the only way to change currencies. Otherwise, order books will be used where available. For example, if you hold bitstamp BTC IOUs and are trying to pay someone who only accepts WeExchange BTC IOUs, it will try to ripple through an account, but it will also look for both a direct order book between the two IOUs and an indirect path through two order books.

(I assume by "exchange" you mean an issuer, not a change in currencies.) Assuming the issuer hasn't issued the first one credit, then it cannot apply. (And gateways don't usually extend credit to anyone.) It can only apply when you are returning IOUs to someone who has extended you credit. At first you can give them their own IOUs and then you can issue your own IOUs.

The network doesn't currently handle all of these cases quite as well as it could when finding paths. We are working on this now.

The only really complicated part is community/personal credit. We're not promoting Ripple for that purpose yet precisely because it is complicated. As a payment platform, it's actually pretty simple, at least conceptually. (Though I personally think that over the longer term, this could grow into Ripple's killer app and change the way people think about money, we're not relying on it happening. And it will take tools that don't exist yet.)

I'm really sorry you feel that way. I hope at least that you're not getting that from what we're saying but from what other people are saying about us. We've worked tirelessly for more than a year now to build a system that we hope will drive the cost of payments, particularly cross-currency payments, down dramatically.

In this case, the paths are alternative ways of performing the transfer. In a more complex case, the paths may be needed together to accomplish the full transfer.

Supplying multiple paths also ensures that the transaction succeeds even if the state has changed between when the transaction is formed and when it is processed. When the final transaction is executed, the paths are taken incrementally to ensure the best rate (from those paths) is given. The rate can change as IOUs are pushed through a path for two reasons: 1) If the path includes an order book, you can exhaust the best offer and have to move to an inferior offer. 2) If the path switches from redeeming IOUs to issuing IOUs, the rate can change. (You have to accept your own IOUs at face value, but you can devalue someone else's.)

To explain 2 in a little more detail, say I hold your IOUs and payment path goes from me to you. So long as I hold your IOUs, I can give them to you and you must honor them at face value. However, when I run out of IOUs, if you have extended credit to me, the path can still work with you getting my IOUs instead of me giving you yours. This can result in a different rate because the issuer of the IOUs and the direction they move has changed.

This is an expanded path showing things like currencies even when they don't change. It's a rippling path with no exchanges involved, all in the same currency. The first node is Bitstamp. So the sender is going to return Bitstamp IOUs to Bitstamp and in return Bitsamp will issue IOUs to rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW. In exchange for the Bitstamp IOUs, rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW will issue their own IOUs to rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E, who will in turn issue their own IOUs to the recipient.

Duplicate paths are caused by a bug. We've been working on pathfinding heavily for the past week. Expect things to get much better over the next week or so.

Your amount format is wrong. Try this:

{
    "command" : "ripple_path_find",
    "source_account": "rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P",
    "destination_account": "rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt",
    "destination_amount": {
        "currency": "BTC",
        "issuer": "rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt",
        "value": "0.05"
    }
}

There are a collection of orderbook display and update issues. We're reworking the way orders are communicated between the server and the client to resolve several of these issues.

The only BTC funds that rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P holds are 0.1 rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B IOUs. The issuer of those IOUs charges a .2% transfer fee when its IOUs are moved from one customer to another, so the most you can deliver is 0.0998003992015968 BTC.

I think he meant a gold mine in the sense that there were lots of bugs.