Translations: German 🇩🇪
SegWit was a soft fork introduced in 2017. There was a giant war at the time between “big blockers” and “small blockers” but I won’t go into that here. For those interested, see the book, “The Block Size War”, by Jonathan Bier, a fascinating history.
Technically, the problem before SegWit was Signature Malleability. This is a property of a signature where a slight modification doesn’t inherently change it, eg, adding leading zero(s). The problem with this is that it allows the creation of other versions of the same valid transaction. The identity of a transaction on the blockchain comes from the hash of the transaction, so two same (but different) signatures will allow two different transaction IDs to be created for the same UTXO being spent.
Only one can be included in the blockchain, because if the other is included in a block subsequently, it would be a double spend, and invalidates the block. That doesn’t seem like a big problem as double spending can’t happen, but it is a problem for the workability of the Lightning Network. LN is based on a network of unpublished counterparty-pre-signed shared-multisignature refund transactions (lightning channels), and duplicate spends (refunds) will make the balances on the network insecure (putting it simply). This required a solution, and the SegWit soft fork came to be. And therefore the Lightning Network came to be.
SegWit stands for Segregated Witness, and “Witness”, at cryptography cocktail parties, and academia, means signature. So from the name, we get a clue as to what it does: it “segregates” the “witness” (ie signature), from the transaction. By removing the signature, any adjustments (malleability), do not affect the transaction hash and so it doesn’t create duplicate transaction IDs for the same UTXO spend.
The signature isn’t exactly eliminated though, it is just removed from the transaction and blockchain. It is still required. If a new section was allocated on the block for this data, that would be invalid in the eyes of pre-SegWit Bitcoin nodes. That’s another way of saying backwards incompatible, or a “hard fork” – that’s a big no-no. Part of the Bitcoin ethos is that there is no rug-pulling anyone who does not wish to participate in changes; everything is optional.
So in order to make this change optional, and not incompatible with older nodes, ie a “soft fork”, a clever “trick” was used. I will explain, but please excuse me if I include some inaccuracies – I am not a cryptographer, have not read the code, and I am explaining what I learned from an online MIT lecture, from memory. For a SegWit transaction, a wallet will place a “0” where old Bitcoin nodes are expecting a signature. The older nodes will consider this “0” as a valid signature, and will not reject the transaction (backwards compatibility achieved).To the Segwit nodes, this is a flag to signal that the actual signature is somewhere else (segregated). Further proof of transaction validity is required for newer nodes. This data is stored in the Segwit data, and shared amongst Segwit nodes. The nodes check signatures here before transactions are considered valid. The blockchain size limit remains at 1Mb, but the Segwit data can include up to 3 Mb of data for each associated block.
One might object to this “trickery” and claim that older nodes are indeed being “forced into changes” – While it sounds potentially distasteful, it is actually not disadvantaging the older nodes who do not wish to partake in the way you might think. There was a sneaky increase to the amount of data stored on a node per block (not the blockchain per se), but I understand this was a compromise made to win the Block Size War and avoid an increased risk of a hard fork.
An old node can continue to accept legacy-type payments (addresses that start with 1) to their own legacy wallet from anyone, even if the payment comes from a Segwit UTXO (addresses that start with bc1q). When the payment hits their address, their own legacy wallet will consider this balance valid. Note though, it never checked that the UTXO chain upstream was truly valid (it checked only “0” signatures, no actual signatures on the SegWit data block). In this way, the old node runner continues in the security of his own rules, but can’t stop other people from doing what they want.
On-chain or Lightning