Ack, that's a good point. If you have an m-of-n, and some money is transferred, you can't usually tell who revealed the key parts. You would just know that it's some m of those n people. That might provide enough cover and plausible deniability for some of them to conspire. Nice catch.

Not quite. Fundamentally, a gateway is an entity that has "withdraw on demand" agreements with a significant number of people. Any of those people who hold the gateway's IOUs can redeem them for something nearly equivalent to the value of the IOU. This effectively "backs" those IOUs and gives them value, making them akin to a check made out to "cash".

The disbursement occurs simply by destroying the XRP. The total amount of XRP in existence is always stored in the ledger header. So you can, if desired, "normalize" your XRP holdings to provide a number that's the same fraction of the XRP in existence.

He's not defrauding anyone. They just write it off. 
https://www.youtube.com/watch?v=rCZRqH7sRyA

That's ridiculous. This was the provision:

"Anyone (including myself) who renigs on their bets will be labeled a scammer on the forums. Theymos will retain the IP addresses of everyone who has committed here and as you are marked a scammer for not paying, you will also be reported to the bitcoin police and tracked. For this reason, it is important that you do not bet more than you can afford to lose. Considering the high probability of fraud from newbie sockpuppets, only established 250+ post users will be allowed to participate, unless they participate through an escrow who will hold their coins. This is up to them to find the escrow although many posters in this thread have agreed to act as such."

That clearly says that getting a scammer tag would just be one of the consequences for failing to make payment. It does not give him, or anyone, the option of accepting a scammer tag in lieu of making payment.

This is a real problem that deserves a real solution. How about specifying the parameters of a useful solution and offering a reasonable bounty for an open source solution to this problem. Then you could use that solution to store the funds securely, plus the project will have contributed a secure way to store funds to the community.

It doesn't at the moment.

Then what do you do in the future when you actually need something?

RIPEMD-160 was used because it produces a shorter hash output. This permits bitcoin addresses to be as short as possible without compromising security. The exact reason why SHA-256 was used in combination with RIPEMD-160 isn't known. The two leading theories are:

1. There was concern that RIPEMD might have some defect. SHA-256 was believed to be more secure. The hope was that the two combined would be stronger than RIPEMD alone.

2. There was a concern about possible weaknesses in the MD structure itself, such as a length extension attack. Two hashes combined result in a composite hash that does not have a Merkle–Damgård structure and so is not vulnerable to these attacks.

Personally, I think the first explanation is more likely.

The idea of a backdoor in an open hash function like SHA-256 or RIPEMD-160 is pretty implausible. Even if there were such a thing that might permit something like constructing something that hashed to a given output, it's almost inconceivable that there could be a back door in a hash function that had the right interaction properties with ECDSA to make it useful against the bitcoin address scheme. It really is extremely implausible -- I'd say at least 1,000 times less likely than other possibilities with comparable consequences.

Nothing. Bitcoin behaves more like a commodity than a currency. What backs gold?

So then I presume you don't think Pirate owes anyone anything. After all, their relying on him was irrational.

I'm not saying that documentation isn't important, but this seems just a bit excessive.

You seem to have a serious reading comprehension problem. My point was not about MPEx at all. It was about what would likely happen if people were free to gamble with the Forum's funds, whether they realized they were gambling or not. (Many stories of people trading with other people's money have unhappy endings.)

You're assuming an attacker trying to discredit Bitcoin who doesn't actually do anything to discredit Bitcoin!

A realistic attacker would deposit a large number of Bitcoins to Mt. Gox and then wait. When he introduces his own rollback chain, it will include a double spend of that deposit to Mt. Gox. This will invalidate all transactions that re-spend those coins, all transactions that re-spend outputs of transactions that spend those coins, and so on. With just a bit of effort, he can invalidate a significant fraction of the transactions that occurred in that time period. He could probably invalidate more than half of them with moderate effort.

He doesn't even need a lot of money to do this. He can deposit, withdraw different coins, and deposit again. He can then double spend both of those deposits, doing double damage with the same coins. (Assuming that double-spending his first deposit doesn't contaminate his own withdrawal. But if it does, then he's already doing major damage.)

"It's not my fault for breaking my promise to you, it's your fault for relying on me to keep it."

"If the tables were reversed, it's entirely possible you would have done something just as bad as what I did."

These are pretty weak arguments.

That said, I do think that the actual damage Matthew did is probably not all that much. Obviously, his victims have every incentive to exaggerate the harm done.

You don't know that. There are any number of ways he could have taken people's money and made himself money because of the bet.

For example, Matthew's bet propped up the price of Pirate debt because people who expected Matthew to honor the debt believed Matthew had reason to think Pirate would pay his debts -- otherwise, why make the bet at even odds? Matthew could have taken advantage of this personally to unload Pirate debt.

There are a number of other possible scenarios.

This is the problem with a non-100% reserve system though. Had someone done something similar with GLBSE or, heaven forbid, Pirate, the forum might not get its money back. This would be an ugly situation for all concerned. The same could apply if someone suffered unexpected large trading losses.

I think you should try for a 100% reserve scheme where the holding addresses are publicly known. Only switch to a different scheme if you can't find enough people willing to help run a 100% reserve system. Using a 2-of-3 or similar key splitting scheme is a good idea too.

That makes everyone who held bitcoins before and through the split twice as wealthy!

The thing is, if it remains split, you both lose money.

Exactly, the current design has no path dependence. The longest chain in existence is the valid chain, period.

Any rollback limit would introduce path dependence. Which chain is the valid chain depends on how you got there.

What I'm suggesting is a rollback limit, but if you encounter a case where you would rollback past the limit, you declare the network in an invalid state until and unless the chain you are on becomes the longest chain. That is, you enter a definitive "failed" state in which you declare the network broken.

If we do nothing, and this rare case happens, the network will be broken, we just will continue blissfully going on as if it was fine.

If we just implement a rollback limit and stay on our chain, the network will silently split. This is a solution that is not significantly better than the problem.

Whether the problem is serious enough that it's worth addressing is another issue. For purposes of this thread, I'm assuming it's a concern worth addressing.

It actually terrible for business owners. It's very hard for a legitimate business to get a consumer to give them money if the consumer is legitimately worried that the business will collapse while holding their money or just run away with their money.