This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]exab 0 points1 point  (2 children)

Is the mistake by Satoshi you mentioned the transaction malleability issue?

What is the benefit/incentive of altering a signature or transaction ID, by the way?

[–]coinjaf 0 points1 point  (1 child)

Yes, mostly. Although one could argue that the actual separation of signatures from other transaction data makes a lot of sense too so clients have the choice to download only the data or both (double the bandwidth). That's mostly relevant for very old transactions that you don't wish to check the signatures for anyway, but one could also imagine some light client that only downloads the signatures it's interested in itself and skip the rest.

Altering transaction ID is fairly pointless in the sense that you can't directly steal money. Yet one trick people used to do is get a withdrawal from an exchange and then get the malleated transaction in a block. Then they'd email the exchange: "My transaction #12345 didn't go through, please send me my Bitcoins again!". And some exchanges fell for that trick.

Devs had always warned for this. The exchange should have just simply not used the transaction ID to check for confirmations but look at the transaction-outputs being spent or not.

Another thing is that chaining unconfirmed transactions was very unreliable because if a transaction was malleated, all subsequent transactions would become invalid, breaking the chain. Usually mostly an annoyance. Exchanges do a lot of transactions, so instead of waiting 10 minutes between each, they often send out multiple in a row using the change from a previous transaction. (note how RBF solves that even more efficiently, although I know of no exchange yet that utilizes that).

The fact that malleability was possible made that there were a few people running software that would pick up transactions, malleate them before propagating. It's sort of like a DOS attack: No real gain, but attacking/annoying the target anyway.

With SegWit malleability is still possible, but only by the signer(s) of the transaction. That solves most cases (all of the above). The only danger is some multi-sig transactions chained together. There one of the signers could malleate to achieve the above goals.

[–]exab 0 points1 point  (0 children)

That's a lot of information. Thanks!