Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

It seems to me the trivial solution (ok, "hack") for this problem is to construct a new bitcoin address for every withdrawal that is used as a staging ground and one-time "identity" for the transaction. So like, rather than MtGox sending a hundred bitcoin to a user's address, and then having to sort-of-fail to detect the transaction as it gets mutated, it sends the money to a temporary address and then empties the temporary address into the user's target address.

Now, any transaction coming from that temporary address (which can also be told to the user as "expect the money to come from this address", which might be separately useful for purposes other than transaction proofing) can be considered to be the transaction in question: the computed hash of the transaction is irrelevant.

Of course, I should not be able to solve this problem after two minutes of thinking about it; so: anyone mind teaching me what I'm missing? I can't imagine I could come up with a solution this simple so quickly to a problem that is apparently so well known and so problematic to such an established player in this space ;P.

The issue isn't really that difficult to solve, it's just that their software was doing accounting badly and losing track of what was spent where when the malformed transaction was spent rather than the one they believed they created.

An attacker can rely on this (the transaction ID from their perspective never confirmed) and ask them to resend the funds. The attacker doubles their money and suddenly Gox has outputs they think aren't spent, but really have been in a transaction ID they don't know is their own. When they roll these "unspent" outputs into new transactions they fail to broadcast, and then we are in the situation we are in today with a number of backlogged transactions.

Fortunately for them if any money has been stolen using this, they probably have the ID of the person in question.

Your system would work as a hack, but for somebody as big as Gox they would have a significant impact on the blockchain size for no good reason.

MtGox made the right decision in shutting off withdraws and not implementing hacks. It's important for this problem to be solved once and for all.

MtGox made a very bad decision in its choice of wording in this press release. It shouldn't have framed this as a "design flaw." The only reason this happened was because of MtGox's custom software. No one else was affected. By definition, that's not a design flaw.

Uhm, no, this is definitely a design flaw. It violates the principle of least surprise for no reason other than "we didn't think of it at the time". That's pretty much the definition of a design flaw.

You don't need to create a new address - just identify transactions by the inputs it consumes and outputs it generates. Since these parts are signed they won't change.

Of course that's much harder, both in terms of algorithmic and code complexity, than just remembering a hash.

Since you can hash a canonical representation of the unchanging parts, and then use that as the (same-sized) key instead of the native txid, it's not that much harder.

And, it doesn't require global agreement to deploy such a workaround.

You could do it that way. Inputs, Outputs and Signatures don't change though. So just keep track of that. With each confirmation the tx-id becomes less and less malleable. At some point then store the tx-id.

Reply on news.ycombinator.com