Segwit moved some transaction data in a new Witness spot. How do old nodes which do not run SegWit agree with the ones that do?
The trick with segwit is that we don't send them that data. We construct a transaction that is valid under the old rules without the witness data, and we basically staple the witness data onto that transaction in the new section. When you propagate transactions through the network, if you have a peer who announces themselves as a "post segwit" node (through their version number), you send them the full transaction -- staple and all. But if they identify themselves as a "pre segwit" node, you remove the witness data and just send them the "stripped down" transaction.
"Old nodes" are happy with segwit transactions because the stripped down versions they receive are still valid transactions. These stripped down transactions don't have signature in them (because that's what we put in the witness section), but that's fine because not all transactions under the old rules "require" a signature: if you are spending from something called an "anyone_can_spend" address, you do not need a signature.
So we have this special format for segwit transactions where you have to use an address that "old nodes" considered "anyone_can_spend," but "new nodes" look at them and say "if the transaction spends from this former_anyone_can_spend_style address, I know that it actually does require a signature, but that will be in the witness section." So they look there and then validate the signature.
Whereas "old nodes" don't know about the witness section (we don't send it to them) so they just don't see any signature at all, but that's okay with them because they also don't know we changed the rules about these particular anyone_can_spend addresses -- they still think they don't need a signature, so they don't mind that there isn't one.
how is [CTV] a soft-fork? Old nodes could accept a transaction which does not meet the new conditions from the new OP_CODE, which would lead to a chain split
They would accept a "transaction," sure, but it will just hang around harmlessly in their mempool unless it gets into a block. And it can only get into a "block" if a rogue miner decides to mine it according to the "old rules." The rest of the network will reject that block and mine new blocks without it, and "old nodes" will then follow whichever chain has the most work. So it won't cause a "meaningful" chain split unless miners are roughly evenly divided on which chain to mine. At most only one miner or so will still use the "old rules," and that's no big deal because the "majority" network will overpower that "minority" network with their greater hashrate, and even the "old nodes" know to follow whichever chain has the most work, as long as it doesn't violate any of their rules.
Which is why, before activating a soft fork, we usually have miners "signal" their agreement on the new rules via the bip8 method or bip9 method before we "go live" -- that way we know the vast majority are ready for the new rules, and a meaningful chain split is less likely to occur.
Remember: once your node accepts a block, that doesn't mean it's there forever in your copy of the blockchain. If a "longer" chain appears with "more work," and this longer chain lacks the block you accepted, your node will switch to the longer chain and discard the block it once accepted. Also, just because you "accepted" a transaction into your mempool doesn't mean you require a block to come out that has that transaction in it. Your node will chug along just fine even if that old-format transaction never gets mined, and even if a miner does add it to their block, your "old node" will discard that block if the rest of the network refuses to build upon it and makes a longer/more-work chain without it.
reply
Thanks a lot that 100% cleared my misunderstandings. Btw GJ on the song on twitter 😁
reply
You're very welcome! I've got a bunch more songs in a similar style but I rarely find time to record them
reply