Alice creates a Bitcoin payment transaction, and sends it to her peers. When we think of a transaction, we really just care about the inputs, outputs, and payment amounts. The inputs, outputs, and payment amount are all cryptographically signed, so Bob can’t steal money or make any semantic changes to the transaction. BIP141 has a number of other improvements as well: it makes a number of significant changes to the Bitcoin scripting language, and will enable the use of cryptographically secure off-chain transaction using the Lightning Network. This padding changes the transaction hash, just as adding trailing whitespace to a source code file would change the file hash. ECDSA private keys. The complementary signature has a different hash, so using the complementary signature will result in a new txid. At this point it’s a race to see which transaction will actually be accepted by the network: the original transaction created by Alice and relayed by her good peers, or the modified version created by Bob. The original Bitcoin implementation was underspecified with respect to how txids were actually calculated (more on this in a moment). Even more fascinating to me is the history of different flaws in Bitcoin, and how they’ve been addressed.
It’s possible that only a small percentage of stolen coins from Mt Gox were taken using this attack, or even none at all. If there’s a problem with the merchant’s ecommerce software, it’s possible that they could “lose” the transaction, meaning they might think you haven’t actually paid them. Therefore, it’s possible for Alice’s peers to slightly modify the transaction. The first flaw is that the original Bitcoin implementation used OpenSSL to verify the DER-encoded ASN.1 transaction data. For this to work the txids need to be immutable, and that was the original intention in Bitcoin. How does this work exactly? Here’s how Segwit fixes the problem. Segregated Witness or “Segwit”. As of the time of this writing, the most likely scenario is that Segwit will get “locked in” later this month, and then activate sometime in August. Alice’s wallet software will debit 1 BTC from her account once the modified transaction is confirmed, since the modified transaction still sent 1 BTC from her account.
The 1 BTC you withdrew will go into your private wallet under a new txid. Later, you try to withdraw your 1 BTC off the exchange, back to your private wallet. Then you’d ask to withdraw your 1 BTC again, and if you tricked the exchange it could comply. The peers then broadcast the transaction to their peers, and so on. This data is bundled into a DER-encoded ASN.1 representation before being broadcast to the network. This became active on block 363,724 which was added to the blockchain on July 4, 2015. BIP66 is simple: it mandates a strict set of rules to how the ASN.1 data is encoded, and requires Bitcoin nodes to reject transactions that don’t conform to the specification. Therefore it’s natural to periodically check the blockchain to see if the transaction has actually gone through, by checking if the expected txid has been added to a new block. Bob can really just change the actual txid shown to humans. In other words, an attacker can change a txid by broadcasting a variation of the transaction that uses the complementary ECDSA signature.
Most Bitcoin clients have an option to show you a txid after you send a transaction. If you control nodes that peer with the exchange, you might be able to change the txid for your withdrawal using transaction malleability. They could also randomize the withdrawal amounts. If the exchange is naive, you might be able to trick the exchange into thinking that it never sent you your withdrawal. Before continuing, I want to re-emphasize that Bob can’t change where Alice’s money comes from, where it goes, or how much is sent. In this post I want to explain one of the most subtle and nefarious Bitcoin flaws of all time: transaction malleability. For more details about the Segwit timeline, read Jimmy Song’s post UASF/Segwit2x Scenarios and Timelines. Fixing transaction malleability is just one aspect of Segwit. The wtxid is calculated according to a strict set of rules over the transaction metadata, without including the ECDSA signature data when computing the transaction hash. The flaw related to DER-encoded ASN.1 data was fixed by the BIP66 soft fork. However, OpenSSL did not do strict validation of the ASN.1 data by default.
