Anyone who is affected by this issue needs to improve their software, period.

The fact that anyone other than Gox is bothered by this shows that they might have been right in claiming that more than just their implementation is susceptible.

Software that's correctly implemented in the face of transaction malleability will not be bothered by these duplicates.

I don't care if they do, as long as I get my coins...

Transaction recasters are a good thing. They make plainly visible an aspect of the protocol that was thus far obscure, and highlight implementations that don't cope with it properly. As long as transactions remain malleable, transaction recasting should be a permanent feature of the network, done by default for all transactions, so that people don't write software that relies on unconfirmed transaction IDs.

Apparently, even the reference client is affected, to the extent that it allows spending of a previous transaction's change based on an unconfirmed transaction ID. This has to be fixed, or else the reference client does not handle malleable transactions as properly as the developers supposed in their replies to MtGox.

Such merchants are using Bitcoin for something it was not designed to do.

Bitcoin transactions take an hour to confirm, on average.

If you want fast confirmations, you need to build a fast confirmation system on top of Bitcoin. This will likely use semi-trusted third parties that reconcile balances with one another, and can be publicly audited through the blockchain.

I think it had to be crippled once it was there. Too much complexity. It should have been just the standard transaction types to begin with. (Though I would have liked a "user data" field for extensions)



I haven't put thought into this, but that does sound like it could have been an improvement. Is there a benefit to MAST over the current Pay to Script Hash concept?

Yes, it is. When your intended solution may likely just create more problems than there were in the first place, it is better not to try.

Currently, at least informed people know that transaction hashes are unreliable. People who understand this are a small minority of Bitcoin users already. Now consider that you implement canonical transaction hashes, which aren't actually fully canonical. Then people rely on them because no one yet knows they aren't. Then someone figures out how to make them malleable. Kaboom.



The core problem, really, is that there's transaction script in the first place. This was an idiotic design decision in an otherwise brilliant protocol, and has caused nothing but grief and pain. We end up with a hobbled transaction script that can't really be used for any of the flexible purposes it was meant for, and a few hard-coded, "trusted" transaction types which don't require a script language, anyway.

If we could just define transaction hash = signing hash, that would be great. But a transaction can have many signing hashes, depending on the number of previous out points used and their pk script. Which signing hashes do we pick? We could concatenate them all, and then hash that. But then, what if a transaction is non-standard, and uses zero signatures? Then it's always malleable.

What if the signatures are of a type that doesn't sign all the new outputs, so the transaction could be disassembled, and its pieces put together to produce a different transaction that spends some of the same previous outputs? Then you can't rely on the transaction hash again, even if it's canonical.



Indeed, that is one risk.



But the entire deployed base of software will fail to do this, so for all practical purposes, you're back to non-canonical hashes again.

Calculate it according to transaction signing rules, which are tricky. (But are implemented in the reference client, so you can copy that.)


? Any modification that changes the signing hash would invalidate the signature.

The problem with trying to have a canonical format is that if you miss anything - anything, a single bit that an attacker can tweak without changing the hash - you're back to square one.

Right, but in the interest of making Bitcoin safer for businesses to adopt, and thereby to increase its spread and value, let's help them avoid common pitfalls, such as relying on transaction hashes MtGox-style.

Am I the only one here who thinks the "malleable transaction" issue is being approached all wrong?

The problem isn't really that transactions are malleable, it's that people are being led to think they can identify a previously unconfirmed transaction, when it's included in the blockchain, by its unconfirmed hash. This is true in most cases, but it's not true in special circumstances, or if you're subject to an attack.

To discourage this misplaced reliance, why not request miners to always modify all transactions before including them in the blockchain? As long as a fair proportion of miners do this, it will be clear to everyone that transaction success should not be monitored by the transaction hash.

I understand that MtGox wants transactions to have some kind of hash they can unambiguously refer to even if they get modified before inclusion in the blockchain. But to achieve this, simply defer referencing the transaction hash until it's actually included in several blocks - wait a day if you need to - and then quote it to the customer. An unconfirmed transaction hash is not admissible as evidence of payment before inclusion in the blockchain, anyway.

MtGox can track transactions internally via the actual transaction script hash that they signed (as opposed to hash of the entire encoded transaction).

Given the complexity of Bitcoin transaction script, coming up with a non-malleable transaction hash to cover all transactions (not only the few standard types) is futile. If we only standardize canonical hashes for standard transactions, the chance remains that something will be overlooked, either by the agreed-to standard or by a particular implementation, and the problem will rear its ugly head again.

No, creating a transaction doesn't mean it gets processed. The problem is that their software is buggy, and has been buggy for what seems like forever. It tends to create invalid transactions that get rejected by the network. The problem was never too bad, so they didn't bother to fix it, until recently it started snowballing due to unknown reasons, and currently as much as 85% of the transactions their system generates are invalid and rejected by the network.

All of the above is fact, what's subject to interpretation is what were the circumstances that led to this issue snowballing. Options to pick from are (1) it happened by accident, and was eventually bound to happen as long as they didn't bother to fix the problem, or (2) they are intentionally triggering the bug to hide a big loss of Bitcoins (stolen by insider / hacked by outsider / lost keys to them / whatever).

Option 2 is why everyone (like me) has jumped to try withdrawing their balance, making it a run on MtGox, and probably making the problem worse. (But if the worst comes to pass, it's better to get 15% of your Bitcoins than nothing)

I initiated 73 withdrawal transactions today, 11 of them successful. About a 15% success rate.

A quick search reveals they've had these problems since ever (both duplicate spends and ignoring coinbase maturity).

It's possible that more people are mining to their MtGox addresses now, triggering the coinbase maturity problem.

It's possible also that the two problems are related (failed transactions lead to more failed transactions), and that the problem is exacerbated now that it has caught the public eye and everyone (including me) has rushed to withdraw their BTC.

That still doesn't help us if they lack the technical competence to solve this. Their inability to effect a fix is astounding.

Since they resumed withdrawals, but apparently without fixing any of the issues causing transactions to fail, I attempted another 34 transactions.

Of those, 6 went through. The other 28 are stalled.

That's about an... 82% failure rate. :/

I was able to find my missing transactions in MtGox's feed, and from a cursory investigation, it seems like the sky might not yet be falling. (I.e., the cause might not be MtGox's insolvency, but rather incompetence, which means we might eventually see our Bitcoins.)

It turns out that one of the outputs that MtGox tried to use to produce my transaction was a recently generated coinbase output which is not yet 100 blocks old - not even at this point, let alone hours earlier, when MtGox tried to spend it. Apparently, people are mining to MtGox addresses associated with their accounts, and MtGox tries to spend them after a handful of confirmations rather than 100, which coinbase outputs require.

There might be problems with other previous outputs, but this would definitely cause a transaction to stall.

I'm somewhat confident right now that this is a big technical snafu based on old bugs that MtGox hasn't bothered fixing in a while (such as the known coinbase bug and the known duplicate spend bug), but which snowballed now that many people have panicked (like I have) and tried to withdraw.

Hopefully, I'm right about this, and we'll eventually see our Bitcoins.

It's still gross incompetence and unimaginable customer service, of course.