The Bitcoin malleability attack graphed hour by hour | Hacker News Reader

The Bitcoin malleability attack graphed hour by hour

righto.com

73 pointskens33 comments

He mentions the timing of the MtGox announcement being odd. What happened at MtGox was somewhat different. MtGox was submitting transactions that were being rejected due to being malformed according to the latest Bitcoin client software. What some users discovered is that they could correct the malformation issues in the MtGox transactions causing them to go through, but they could also change the hash transaction id, so that meant that not only could they make the transfer go through, but they could do so while making MtGox's software believe that it in fact had not gone through since MtGox was using the transaction id hash to verify a transaction.

When a transaction was rejected by the Bitcoin network that MtGox sent, the MtGox software would detect the rejection and immediately re-credit your account for the attempted transfer amount. MtGox also had an api that allowed you to see the exact contents of the transactions that they sent to the Bitcoin network. This meant that what someone could do is just grab the rejected transaction, fix the malformed portion, modify the transaction id hash and resend the transaction, causing it to go through, but MtGox was unaware of the successful transfer and would re-credit the account. The user could then rinse and repeat over and over.

The interesting twist of this is that it means MtGox knows which user accounts were used to steal coins from them since the malformed transaction could be modified to change the transaction id hash, but the receiving bitcoin address could not be modified without invalidating the transaction.

if MtGox knows the thief's account, what can they do to remedy their losses?

Probably not much it depends on if it's a hacked account or not and then if they do in fact know the identity of the hacker then it becomes a legal thing. They can't do anything to revert the theft. It would be an interesting court battle over bitcoins.

Ignorant idiot here will assume the role of First Person That Finds This Interesting But Has No Real Clue What It Means title.

Could someone outline loosely what the implications are of this in layperson's terms?

Thanks.

transactions, which move bitcoins from one address to another, must be signed by the sending address.

however, not all parts of a transaction are signed. modifying those parts allows one to create a valid transaction with the same bitcoin transferring effect, but with a different overall hash.

the hash of the entire transaction is used as a transaction id.

so a modified transaction would have a different id.

some bitcoin management software (a wallet) loses track of transfers, because those transfers don't occur under the transaction-id it expected.

the implication is that some bitcoin services could get confused about who they've successfully sent bitcoins to.

an attacker could socially engineer a "robbery" by transmitting a mutation of an official withdrawal transaction, then appealing to the helpdesk of that service that their withdrawal never went through. it did go through - just under a different transaction id.

checking transaction hashes for acceptance into the blockchain was a stupid idea to begin with. clearly the data in a transaction is malleable without affecting the signature. given that mtgox already were using non-canonical transactions, they should have been aware of this.

a transaction only becomes immutable once it has been included in the blockchain. after this point, searching for a tx by hash is ok.

calling this a bug of the bitcoin protocol is akin to saying that array decay in C is a bug in the language spec. it is known, and and has been talked about for a long time. in both cases.

Thanks for taking the time to explain this, I've been curious myself.

Do you know why scripts aren't signed? I don't fully understand bitcoin but it seems like they're an integral part of the transaction.

scriptSig (the second part of the script) contains the signature - it can't sign itself, but you can add other opcodes to it and that allows malleability.

More seriously, if the software was set up to retransmit bitcoin after a "failed" transfer, then that service could be exploited automatically. Mostly, this wasn't a social attack. The seriousness was that many services were set up to retransmit automatically, and did lose a lot of money automatically.

I'm still not sure what's the best way to defend against that, so I posted a "Ask HN" here: https://news.ycombinator.com/item?id=7246381

Any help is appreciated

Instead of relying on transaction hashes, you need to scan the blockchain for any transaction involving the addresses you care about.

Transaction hashes are a misnomer -- the hash is a has of the message, NOT of the transaction. Many messages match one transaction.

There was quite a good explanation posted to HN 5 days ago: http://cryto.net/~joepie91/blog/2014/02/10/why-mtgox-is-full...

(discussion: https://news.ycombinator.com/item?id=7211286)

I found this explanation, also from the same blog and also posted here, to be quite clear: http://www.righto.com/2014/02/bitcoin-transaction-malleabili...

Discussion: https://news.ycombinator.com/item?id=7232175

I think it also serves to give a visual confirmation of just how much bullshit "transaction malleability" is when used as an excuse for the theft of 4,500BTC from SR2: http://www.deepdotweb.com/2014/02/13/silk-road-2-hacked-bitc...

Discussion on HN: https://news.ycombinator.com/item?id=7234010

This isn't really an attack, is it? I mean, the money still gets from who it's suppose to get from to who it's suppose to get to?

It's only an "attack" if your wallet software doesn't validate against the recommended (iirc: to_addy, from_addy, amount, time-in-tx), correct?

I think this may be the way for attackers to force price of BTC to fall down, then buy tons of them to sell when the price goes up again.

How does TM affect the price?

It causes FUD and panic.

I can cause FUD and panic w/o TM though:-p

Well pointing out that large implementations thought they had a transaction ID, and that the transaction ID can just change later -- that's some decent technical-level "FUD".

Yes, the modified Bitcoin transaction performs exactly the same transfer between the same addresses. There is no double-spend as far as the Bitcoin system is concerned since only one of the transactions will get confirmed by miners.

Linguistic arguments are kind of pointless, but it's still an attack even if they are just trying to disrupt the system and not steal anything. e.g. a denial-of-service attack.

Various definitions of "attack" are at http://en.wikipedia.org/wiki/Attack_(computing)

But if you handle tx properly it doesn't disrupt your system.

The seriousness of this attack is that several major bitcoin services lost a lot of money because of it. It's an attack.

It's an attack, it's just not an attack on Bitcoin.

This is mincing words. It's an attack on bitcoin. Many major exchanges were shuttered while they dealt with it, for example.

It's certainly not an attack on not-bitcoin, so therefore it's an attack on bitcoin.

There's an attack on credit cards because Target had a breach!

See, I can say ridiculous things too. Someone using bitcoins didn't follow protocol and as such as scammed out of money. This isn't a bitcoins-protocol issue, this is a people issue.

Note that the other exchanges are up now, very quickly after everyone stopped to check themselves.

The Target hack certainly disrupted the credit card system, by causing a lot of reissued cards.

That doesn't really disrupt the system though. It's not causing issues for anyone who hasn't had their card canceled and reïssued.

Bitcoin the protocol? Bitcoin the idea? Bitcoin the network? Bitcoin the whole ecosystem?

I would argue it was an attack on Bitcoin the ecosystem, due to an _oddity_ of Bitcoin the protocol. Bitcoin the idea is still fully alive. The attack worked from within Bitcoin, the network.

This causes another problem. Even if you have a lot of coins from a former transaction, when you spent a little the remainder coins (change) have to be blocked for 1 hour (6 blocks) until the transaction is "confirmed".

The standard client just assumes that the transaction is legit and you can use the remaining coins immediately. But to use these coins the program has to know the ID of the transaction.

But due to the malleability, it's possible that the ID that is generated in your client is not the same ID that is finally added to the blockchain. If you use the original ID and it is changued, then the next transactions will be invalid. So you must wait to see the final ID and use it to create the next transactions.

This is not an attack. If anything, it serves to make the bitcoin ecosystem stronger. A course of anti-bionics if you like, forcing the network to build up safeguards against the lack of understanding of this characteristic of the protocol.

Ah, yes. X makes Y stronger, NOT-X also makes Y stronger. Can't have it both ways, I'm afraid.

You can if the transition from one to the other is what's doing the strengthening.

Reply on news.ycombinator.com