> <i>These txids are immaterial to how the Bitcoin blockchain works: their primary use is as a convenience for humans when referring to transactions.</i><p>This is incorrect. Each Bitcoin transaction input references a previous transaction output as the txid+output index. Transactions spending unconfirmed outputs are orphaned when the parent is malleated and confirmed.<p>Also, as a data hash with no checksum, txids are not convenient for humans at all.<p>> <i>Transaction malleability is already more or less fixed in Bitcoin</i><p>A couple months ago, there was a significant malleability attack on the Testnet, in which nearly every transaction was malleated as it was included in a block.
> However, OpenSSL did not do strict validation of the ASN.1 data by default<p>The more interesting problem was that this was non deterministic, you could encode fields with 64bit integers and they would bomb out on 32bit systems. ASN1 is also mind bogglingly complex, you can encode to arbitrary depths completely nonsensical things like negative numbers and strings, containers of multiple elements, none of the implementations manage to decode blocks the same or adhere to the same limits.
There's a list of nine different types of malleability here: <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki" rel="nofollow">https://github.com/bitcoin/bips/blob/master/bip-0062.mediawi...</a><p>And if you want to see what a malleability attack looks like at the byte level, I analyzed one three years ago: <a href="http://www.righto.com/2014/02/bitcoin-transaction-malleability.html" rel="nofollow">http://www.righto.com/2014/02/bitcoin-transaction-malleabili...</a>
This is a very complicated way to explain TX malluability. It'd say that the problem is that signatures only sign a portion of the transaction and the resulting TXID that is used in the blockchain is based on hashing the entire transaction.<p>So the signature can be mutated as the author suggests, but the signature doesn't sign the entire section of the transaction anyway (where data is provided to the redeemScript to satisfy its conditions. This section called the scriptSig includes the sig which cannot sign itself.)<p>So with the scriptSig, anyone is free to add whatever new data they like to this section which gets added to the input stack, and as long as you leave the stack the same way as you found it you can insert any arbitrary junk as you like and it will change the resulting TXID as seen in the blockchain without invalidating the transaction.<p>This is a bad thing for "smart contracts" on Bitcoin because many contracts depend on making chains of unconfirmed, future transactions, based on hashing the entire transaction to compute its TXID (as Clarkmoody suggests.) An example of this is a cross-chain contract where you might want to send funds to a partially shared address between a stranger and yourself, and you need a way to setup a time-locked refund in case the protocol doesn't succeed (no longer necessary due to OP_CHECKLOCKTIMEVERIFY but its an example.)<p>To do refunds in this way you would need to be able to sign chains of unconfirmed transactions without previous transaction IDs being changed from transaction malleability. Bitcoin does include a fix for this called "segregated witness" but the fix has been controversial. I don't keep up to date with the "scaling progress" now but I doubt it has been merged yet.
One thing that strikes me as weird is the reference to ASN.1, I always thought that bitcoin only uses DER encoding for the signatures themselves (because that is what is usual for ECDSA, even thought it is suboptimal for multiple reasons) and the rest of the protocol including transaction format is specified in terms of bytes and varints. Have I missed something?