Hacker News new | past | comments | ask | show | jobs | submit login
Update on Transaction Malleability (bitcoinfoundation.org)
33 points by sheetjs on Feb 12, 2014 | hide | past | favorite | 11 comments



This puts a new spin on mtgox hate, for once something is not their fault and it appears they were honest in their announcement.


If they were expressing a concern about a legitimate risk in the system wouldn't something like the security list been the right avenue, and not an accusatory press release?

You'll note that mtgox had funds taken from it, none of these other sites are. They're just being flooded with junk that screws up their transaction processing. It's not really the same thing at all.


You'll note that mtgox had funds taken from it

Source, please? How much did mtgox lose?


I (Greg Maxwell) am the one of the two "Bitcoin core developers" mentioned in the MtGox press release. My source is Mark Karpeles directly.

I do not know how much they lost. Most of my discussion with them was before I think they knew exactly how much they lost. I had assumed, by the nature of the issue, that it wasn't likely to be much. I'm a little less sure of it based on their behavior since this weekend and due to finding out that there software was automatically issuing reissuing transactions that it didn't think had been paid out.


An enterprising blockchain-spelunker might be able to put a very rough ballpark estimate on amounts lost by any affected repeat-payers, by:

(1) Find all confirmed transactions that have a signature that appears in non-canonical form (and thus likely confirmed under an unexpected TXID);

(2) For those transactions, identify the paid-to addresses and amounts: possible targets of make-up transactions. (Of course, it may be hard to distinguish true targets from 'change'.)

(3) Find later transactions with the exact same paid-to addresses and amount: these may be erroneously-issued repeat payouts.

Of course, if the complaining user offers a different address for the make-up transaction, this wouldn't work. On the other hand, a researcher already working hard to correlate affiliated addresses, now or in the future, still might be able to surmise when duplicate-amounts went to affiliated-addresses in succession during the active exploitation period.


> (1) Find all confirmed transactions that have a signature that appears in non-canonical form (and thus likely confirmed under an unexpected TXID);

Unfortunately, you can't— MtGox had a long standing bug where they would author transactions which were themselves non-canonical form (they encoded the variable length values in DER as fixed length with excessive padding). This is one of the reasons their transactions were getting stuck.

People mutating their transactions removed the padding, making them canonical.


Aha, interesting. Seems someone could still run a similar process in reverse: if MtGox's successful make-up transactions are non-canonical, find those first, then look for canonical precursors, within the suspected-exploitation timeframe.

That seems more prone to false-positives, though, and perhaps after some point the flood of copycat non-canonicals becomes a problem. (On the other hand, if MtGox was fairly unique for a while in issuing a particular kind of non-canonical transaction, it could make mapping their affiliated addresses by some larger effort easier.)

Some researchers might have records of most of the alternate transactions that were circulating without being confirmed. For example, I don't know how comprehensive Blockchain.info's double-spend report – https://blockchain.info/double-spends – is, but I imagine TXID-mutated variations might appear as double-spends there. It's currently reporting 1126 detected double-spends - over 1000 in the last 3 days, but before then, quite rare.)


I don't think MtGox has confirmed any losses, nor would I expect them to. But consider both the way they've spoken about the issue (https://www.mtgox.com/press_release_20140210.html)...

"In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their transaction did not go through."

...and nullc's speculation just before the latest blamestorming (http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_cha...)...

"Worse, some of this may have resulted in users getting paid multiple times and could have been intentionally triggered with that end in mind if someone helpfully fixed some transactions and then noticed they got paid twice. (I think this is unlikely to have caused large losses, before people run off worrying about that, both because of the reuse of the oldest inputs and because of the hot wallet/cold wallet split)."

Thus I find it reasonable to surmise, based on MtGox's own description of the risk, that MtGox has in some cases issued unnecessary redundant payments to customers complaining that "it's been days and the TXID you reported still hasn't shown up!"

An earlier MtGox issue nullc also mentions – using too-young coins – could similarly have resulted in double-payments. (MtGox issues a transaction that can't confirm; customer complains and gets 2nd transaction issued that confirms; first transaction later confirms when coins have aged enough.) If so, that perhaps helped train MtGox customers, even if not MtGox itself, for the redundant-payment potential from malleability.


I think it is exciting to see mass attacks that aren't really bringing the network down. It actually builds my confidence in Bitcoin.


It is so exciting to know that a script kiddie can knock double-digit percentages off the value of the currency while causing the community to fragment into infighting and calling each other "full of shit". That really builds my confidence in Bitcoin.


That's really not fair. Bitcoin is still young and considering that it's surprising we don't see more incidents like this.

Where is it written that it was a script kiddi. If this was the work of just a script kiddie, we would be seeing incidents like this all the time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: