Unfortunately, due to a server bug, some history was lost. You can't trace all the way back to the genesis ledger. You can trace back to ledger 32,570. All history after the beta was opened is available. All that was lost was the ledger headers -- all the transactions are still available, so there's some hope that the history may still be recovered.

In each ledger, there is a header field that tracks the total amount of XRP in existence. It is easy to check that the total XRP in the ledger equals the amount in the header and that the header field equals the previous ledger's total less the total of all transaction fees. There are no mechanisms to create or destroy XRP and any change that did so would be immediately detectable.

All ledgers (after 32,570) are publicly available. Each ledger contains the hash of the previous ledger and all the transactions that were applied to turn the previous ledger into this ledger. Each transaction is signed by the account that issued it and is bundled in the ledger along with metadata explaining precisely what ledger entries it affected.

If, for example, XRP were to somehow appear, there would have to be an accepted ledger before the XRP appeared and an accepted ledger after the XRP appeared. All these ledgers would be signed by the majority of validators or they wouldn't have been accepted. In the first ledger after the XRP appeared, there would either have to be a transaction whose metadata included the increase in XRP or not. If not, then there is 100% conclusive evidence that a stated invariant was broken -- an account's balance may not be changed without a transaction whose metadata shows that change. If so, then there is still 100% conclusive evidence that a stated invariant was broken -- an account's metadata may only change the total XRP in the ledger by destroying its transaction fee.

This would all be conclusively provable by anyone who cared to look.

We've explained this several times in many places. There's a very important reason not to release the source too early -- once the source is released, the system is very hard to change.

Imagine if Bitcoin had gone open source before the decision to decrease the block reward was made. Groups that had invested in mining might oppose the choice to make the block reward schedule decrease, even if that was in the long-term best interests of almost everyone. We chose a plan that allows us to get community input while the design can still be changed, and we are still making changes to the design based on community input. (We believe we now know what the design will be when we open source. So we're not changing that design, just finishing it.)

As soon as the source is open, design changes will require convincing the community. And even some design changes that almost everyone wants may be very difficult to do.

Yeah, it's silliness. One of the major differences between Bitcoin and the systems most people would compare Bitcoin to is that Bitcoin is much more anonymous. This makes it perfectly reasonable to describe Bitcoin as "anonymous" in a brief description or as a tag line. To call people "liars" or "frauds" because of such a description would be lunacy. Of course, anyone who wants the details can easily find out precisely how anonymous or not-anonymous Bitcoin is.

More specifically, it's the difference between hard money (cash or its equivalent) and soft money (promises to pay). Americans particularly are not used to dealing with hard money systems, other than cash, because American banking and consumer finance is pretty much all soft money. Gox is a hard money system. When you send Bitcoins to someone's Gox deposit address, it's supposed to be, semantically, as if you handed that person cash. This rule is needed because Bitcoins can very easily leave Gox as hard money and the only practical way to soften the money would be to add friction to this path.

I'm not sure who the "they" is here. If you mean Gox, I'm not sure how much effort it is fair to require of them to work around other people's assumptions that are known to be broken.

It is if you investigate it. I would analogize it to intentionally depositing money in the wrong bank account -- if some company keeps sending them money over and over addressed to the wrong account, at some point the bank has to draw the line. It's not fair to expect them to continue debiting the accounts of innocent customers incorrectly credited by someone else's mistake. It's not unreasonable for them to say that they'll credit the accounts the depositor asks them to credit rather than having to constantly tell innocent customers that their balance is wrong.

If you force people to use a password, they use a lame password or store it in a file right next to the data it's supposed to protect. An attacker can tell how many Bitcoins are in the wallet and can devote significant brute force resources to only those wallets known to have significant funds in them.

Right. The point is that Gox did the right thing. You can argue endlessly over whether Bitcoin is broken because it doesn't provide a return mechanism, SD is broken because it acts as if Bitcoin did provide such a mechanism, SD is broken because it didn't provide adequate warnings, the user is at fault because they didn't pay attention to the clear warnings, and so on. But there is no way this is Gox's fault. Either SD didn't provide adequate warnings that they make unusual assumptions or the user didn't pay attention to adequate warnings. Gox's behavior here is completely normal and, most likely, they credited the deposit to another user because SD sent the deposit to some other user's deposit address.

There is no simple way Gox can make this work.

Right. And, to be clear, I'm not arguing that means that these other coins are fundamentally broken or anything like that. I am saying that their attempt to "fix Bitcoin" has produced a system that is in fact worse. I do agree that there might be a small advantage in that mining may be more distributed.

Right, but the problem is that it traces to a MtGox account that is not yours. MtGox uses Bitcoin accounts to receive money. When they spend that money, it comes from their receiving addresses. So your payment went to someone else's receiving address.

I have a deposit address at Mt. Gox. Say I send 10 BTC to that account. The 10 BTC will be sent to *my* Mt. Gox receiving address. Now, say you send 1 BTC to SD. If it uses some of my 10 BTC, which it might, then your transaction's sending address will be my transaction's receiving address. To Mt. Gox, it will look like I am depositing more Bitcoins.

IMO, it is SD that is broken. It does not make sense to automatically send Bitcoins to an address just because it sent Bitcoins to you. There is no way to know that the recipient will bear any logical relationship to the actual sender.

For every person who mines on a CPU just for the heck of it, there's an equal and opposite professional miner who is discouraged by the increased difficulty. So while the identity of miners might be more diverse, the proof of work will be the same. However, to mine on a level technological playing field for Bitcoin will mean you have to invest in ASICs. Anyone who tries to attack Bitcoin without ASICs won't even get out of the door.

The point is that ASICs do *much* more work, leaving anyone who tries to mine without them at a massive disadvantage.

No. To compete on a level playing field with miners, someone attacking Bitcoin has to invest in ASICs, otherwise they're at a massive technological disadvantage.

Yes, the total amount of proof of work will be the same in both cases. You won't have more mining because you don't need to invest in ASICs, you'll just have more casual miners and thus fewer professional miners.

If you really don't see it, consider two coins with exactly the same money spent on mining except one uses ASICs and one uses CPUs. Which one can you more easily attack with a bot net? Which one can you more easily attack with rented hardware?

Bitcoin got this right and people who don't understand security are mindlessly trying to fix what is not broken.

I agree that this is a threat that has to be kept in mind. I'm not convinced that it's a more serious realistic risk than the threat of a 51% attack on a proof-of-work based system.

This is very bad. Bitcoin got this right. These other schemes are much weaker than Bitcoin's. To attack Bitcoin, you have to invest millions of dollars on mining ASICs that will become worthless if your attack succeeds. To attack these other coins, you just need a botnet or to rent some general-purpose computing power.

I think it's too early to tell especially given the extensive testing that proof of work has received. But I'm very optimistic. Two big fundamental differences: Proof of work can also be used to distribute a currency -- there's no known good way to do that using consensus. There's no known good way to handle a 51% attack on a proof of work system.

I'm not sure Bitcoin could survive this for two reasons. First, it would force people to leave fiat in an exchange for as little time as possible. This would mean people forced to exchange quickly rather than when it makes the most sense. This will force people to take currency exchange costs they could otherwise avoid by timing. Second, it would increase the incentives for legitimate businesses to distance themselves from Bitcoin. If nothing else, they'd have a hard time figuring out where to exchange them this month.

But I don't think that's going to happen. I think exchanges will comply with the regulations. I doubt LR or BTC-E have any particular interest in financing terrorism or helping to launder drug money. (Or, if they do, they can be replaced by similar businesses that don't.) They just need to figure out reasonable ways to comply.

As a result of extensive discussions with users, we're going to make it so that pathways, by default, cannot be "rippled through" unless the previous link in the payment path was a redemption. I don't think that will do much to avoid this "exploit" -- you can probably just convince people to change the default. But it will allow people to hold balances from more than one gateway in the same currency without having as much exposure to a single unstable gateway.

On the bright side, the reduction in free liquidity will mean more opportunity to provide liquidity at a profit.

I'm not sure what that would be. If you want me to imagine they come up with some perfect way to do it and then ask me if the perfect way is better, then yes, the imaginary perfect way will be better.

I'm sure there will be such a spinoff, perhaps several. I'm not afraid of competition. We did things the way we did it because we genuinely believed that was the best way. If we were wrong, then the better way will win. I will not be terribly upset if the concept wins even if the company doesn't. There are millions of ways to fail and those are among the best.

If we had been able to think of a better way to do it, we would have done it that better way. If other people can think of a better way than we did, then they deserve to win and we deserve to lose.

I'm serious -- we did things the way we did because that was what we believed was best. Not just for us, for everyone. If we were wrong, then so be it.

He proved that it's possible to do useless and bad things with Ripple. The same is true of a hammer.

It seems like an absurd waste of electricity to me. Mining in Bitcoin is essentially paying people to solve the double-spend problem, rewarding them for providing a useful service. Mining in a system that doesn't require proof of work to secure it is pure waste. It is as silly as Opencoin having an XRP giveaway to whoever wastes the most electricity.

And, again, if we fail because we inspire something that people like better, that's probably the best possible way to fail. But I think that's one of the worst ideas for a Ripple spinoff.

The pathfinder *should* always prefer to return a person's own balances to them. It is a system invariant that one must always accept one's own balances at face value. However, it may not be all that well tested. Being able to see the transaction paths prior to sending would be a really nice feature to have and a manual feature to directly adjust the balance of a pathway is planned.

That's a large part of the reason we designed it so that we wouldn't be running it. Ultimately, we think it's adoption of Ripple as a payment network that will drive demand for XRP. We're willing to take the risk that we're wrong on that, as we've taken so many other risks. If we fail because Ripple is successful as a payment network and demand for XRP just doesn't arise, well, of all the many ways we could fail, that's not too bad. Our primary strategy is to remove every possible drag on adoption of Ripple as a payment network and do everything we can to drive adoption.

We don't think so. We think long term that driving adoption is the right strategy both for growth of the payment network and for eventual value for XRP.

We don't care about the value of XRP over that short a term. If people are forced to buy XRP, some people won't adopt Ripple because of that. Our success strategy is exponential growth for many years. Sacrificing growth now for a short term boost in the price of XRP would be foolish.

Any time you want to live in the same reality as the rest of us, we'll be here waiting for you.