After a holiday break, todays newsletter starts chapter 3 from Bitcoin: A Work in Progress.
When I visited Austin a few weeks ago, I had a chat with Marty Bent on his Tales From The Crypt podcast. We covered a bunch of topics from the book, and more! You can watch it on Youtube or look for TFTC episode 383 in your favourite podcast app.
Segregated Witness, also known as SegWit, was a soft fork activated on the Bitcoin network in the summer of 2017. It was the last soft fork before Taproot activated in the fall of 2021, and it’s arguably still the biggest Bitcoin protocol upgrade to date.
In short, SegWit allowed transaction data and signature data to be separated within Bitcoin blocks. This chapter will explain how it works and go into detail about the benefits of it.
Before SegWit arrived on the scene, there was a problem with transaction malleability. Each transaction has a unique identifier. When someone sends you coins and you send them onward to someone else, your transaction (B) uses the identifier (ID) of transaction (A) to refer to it. Now if both transactions are unconfirmed, a problem can arise when a malicious person grabs transaction A and manipulates it. This manipulation changes A’s ID. As a result, transaction B now uses an outdated identifier to refer to transaction A, which means it refers to a void. A transaction that tries to spend from a void is invalid and never makes it into a block. This is a confusing experience in the best case.
A well-known example of transaction malleability, is what happened with Mt. Gox, a bitcoin exchange from Japan. According to some sources, Mt. Gox was doing its internal accounting based on transaction IDs. A customer would withdraw funds, use malleability to change the withdrawal transaction a little bit and receive the money because the transaction was still valid, but then claim, “I made a withdrawal but never received the money.” In response, Mt. Gox would use the transaction ID and look to see if it was in the blockchain. It’d see there wasn’t a transaction ID in the blockchain that matched, reason the customer was right, and resend the coins.
More specifically, the part of the transaction being manipulated is the signature: Every transaction is signed with a cryptographic signature. Prior to SegWit, there were lots of ways to tweak this signature so that it looks different but is still valid, with the amount and recipient unchanged. Only the transaction ID changes.
One way was to put a minus in front of the signature — remember a signature is just a big number — and anybody could do that (Resolved with BIP 66): When you broadcast a transaction, it goes from your node to another, and onwards from there. The aforementioned malicious person would see that transaction appear on their node, grab it, flip this bit and send it onward. At that point two versions of the same transaction are being spread through the network, and only one of them will make it into the next block.
So you may ask yourself, “Why is this a problem?” It’s not necessarily a problem in the scenario we started with, where you receive coins and send them onwards. If a malleated version of transaction A makes it into the block, you just make a new transaction (B) that refers to A’s new transaction ID.
But imagine you sent a transaction (A) to a super secure vault in the Arctic located thousands of meters underground. And then you went to the Arctic and created a redeem transaction (B) back to your hot wallet, and you signed it, but you didn’t yet broadcast it. Then, once you broadcast the first transaction (A) to send some money to the vault and somebody messes with it, suddenly the second transaction (B) is no longer valid, since it refers to the unaltered one (A). Now you have to go back to the Arctic to create a new transaction (B) that refers to the altered version (A) — a scenario that’s complicated at best. This example may seem contrived, but vault designs have to take malleability into account.
Another, perhaps more down to earth, example of how this becomes a problem is with the Lightning network, which is where you’re building unconfirmed transactions on top of each other. So if one of the underlying transactions is tweaked, the transactions that follow up on that one are no longer valid.
In the Lightning protocol two people send money to a shared address, and the only way to get money out of that address is by using a special transaction that both parties signed before they sent money into the shared address. You don’t want somebody messing with the transaction that goes into the address, because then you can’t spend from it anymore — or rather, you can, but you both have to sign it again. That potentially gives one party the power to blackmail the other to get their fair share of the coins back.