pull down to refresh
624 sats \ 4 replies \ @supertestnet 8 Aug \ on: How are these not hard-forks? bitcoin
Let's suppose we took the current block size limit, 4mb, and decided that on January 1 we will reduce it to 2mb. Now, Grandma Gemma doesn't want to upgrade, so she keeps running an old node. On January 1, what happens?
Well, Grandma Gemma's node doesn't require blocks to be 4mb -- it will accept anything 4mb or less. Suddenly she starts seeing 2mb blocks. No big deal -- she accepts those too. That's why it's a soft fork, old nodes don't mind the new rules. But let's suppose some rogue miner decided to mine a 4mb block after January 1. What happens?
Well, most of the network rejects that block, because it violates the new rules, but Grandma Gemma accepts it. Chain fork, right? Not so fast: nodes follow the "most work." So unless the rogue miner has more hashrate than everyone else, the chain with "small blocks" will "outgrow" the chain with "large blocks" -- and as soon as Grandma Gemma's node sees a longer chain with more work, she will discard the "big block" and go with the longer/more-work chain.
That is why making the block size smaller is a soft fork: it doesn't cause a meaningful chain split as long as most miners are on board with it. It doesn't have to be all, just more than 51%.
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.
reply
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