How are these not hard-forks? \ stacker news ~bitcoin

pull down to refresh

1964 sats \ 15 comments \ @snufon 8 Aug bitcoin

I'm having trouble understanding how some soft-forks did not cause a chain split.

Increasing the block size is a hard-fork. That seems obvious: if old nodes dont accept larger blocks, they would not agree with nodes running software accepting large blocks. The large blocks would be refused by old nodes, creating a blockchain split.

However I remember reading that decreasing the block size would be a soft-fork. Huh? The same kind of disagreement between nodes running the old and new software should happen again right? Is it because all miners would signal their approval for smaller blocks first, then mine smaller blocks from then on? So that old nodes would only ever see blocks smaller than their higher, older limit? Do such soft-forks always require miner cooperation first?

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? They are not aware of the Witness part, how/why do they accept the same transactions as valid without that data?

More recently I read very interesting proposals for soft-forks enabling covenants such as CTV. This would enable new spending conditions for UTXOs, thanks to a new OP_CODE to Bitcoin Script. This could notably allow multiple people to own different parts of a single UTXO from what I understood, which would solve the usual complaint that "onboarding billions of people on L2 with one UTXO per person takes too long/too costly".

Again: how is this 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. Maybe the miners only relay valid CTV transactions, and the nodes ignore the unknown new OP_CODE so they think it's valid?

Thanks a lot for your help!

view all related items

624 sats \ 4 replies \ @supertestnet 8 Aug

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%.

364 sats \ 3 replies \ @supertestnet 8 Aug

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.

464 sats \ 2 replies \ @supertestnet 8 Aug

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.

0 sats \ 1 reply \ @snufon OP 9 Aug

Thanks a lot that 100% cleared my misunderstandings. Btw GJ on the song on twitter 😁

100 sats \ 0 replies \ @supertestnet 9 Aug

You're very welcome! I've got a bunch more songs in a similar style but I rarely find time to record them

247 sats \ 2 replies \ @WeAreAllSatoshi 8 Aug

Making something smaller would lead to wasted or unused space, but isn’t necessarily incompatible. That’s why I think decreasing block size would be a soft fork instead of hard. This differs from increasing in that you can’t fit something larger in something smaller, hence hard fork

332 sats \ 1 reply \ @ek 8 Aug

I think OP is talking about miners running the old version mining blocks that are too big for the new nodes and thus causing a similar chain split. Instead of old nodes rejecting new blocks, new nodes would reject "old" blocks (new blocks that are mined with old consensus rules).

So I think this is the essential question:

Do such soft-forks always require miner cooperation first?

Yes, according to my knowledge, that is the case.

See the Segregated Witness Upgrade Guide:

Initial segwit adoption requires the participation of two groups:

Miners representing 95% or more of the total Bitcoin network hash rate must signal support for segwit in order to lock-in segwit’s activation.

Full nodes run by a reasonable number of users and business to validate the payments they receive need to be upgraded to Bitcoin Core 0.13.1 or above, or another segwit-compatible implementation in order to incentivize miners to follow segwit’s rules after segwit activates. (This is Bitcoin’s normal incentivization mechanism where miners only receive income for generating a block if they follow all of the consensus rules, which will include the new segwit consensus rules once segwit activates.)

0 sats \ 0 replies \ @snufon OP 9 Aug

deleted by author

432 sats \ 1 reply \ @ChrisS 8 Aug

A soft fork is forward compatible. Soft forks restrict block acceptance rules. Hardforks are not forward compatible and expand the rules. So like you say increasing the block size would be a hardfork because old nodes with a limit would not count a block larger than than that limit as being valid thus the old nodes would be broken compared to new nodes. Decreasing the block size however would be forward compatible because old nodes would still consider the smaller block size valid. Eventually if the change was accepted by enough nodes the network will still move towards all the block being smaller but in the meantime old nodes can still continue to work on the network as before.

Segwit scripts are OP_0 followed by an 20 byte hash. Old nodes accept this script as valid because the top element is nonzero. Newer segwit nodes have a special new way to validate this type of scripts which includes knowing to look for the witness part of the transaction. Again forward compatible so a soft fork. Segwit was activated by the user not the miners. This chapter in @jimmysong book explains it much better than I could. https://github.com/jimmysong/programmingbitcoin/blob/master/ch13.asciidoc.

Here are a couple links explaining hard and soft forks. https://learnmeabitcoin.com/technical/blockchain/soft-fork/ https://learnmeabitcoin.com/technical/blockchain/hard-fork/

0 sats \ 0 replies \ @snufon OP 9 Aug

deleted by author

232 sats \ 1 reply \ @ek 8 Aug

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? They are not aware of the Witness part, how/why do they accept the same transactions as valid without that data?

The answer is here:

When a block containing native segwit transactions is propagated to pre-segwit nodes, the witness scripts that unlock the segwit inputs are not sent; pre-segwit nodes think that segwit inputs are "anyone can spend" utxos, and consequently they don't expect a witness script for transactions that spend them, because no script is needed to unlock an "anyone can spend" utxo.

-- #57408

So if you're running an old node, you're not fully verifying transactions spending from segwit outputs according to segwit consensus rules. Your node assumes anyone could have spent them according to pre-segwit consensus rules. I think this is what made it possible to activate SegWit as a soft-fork.

I have been confused by this for a while, too. This question actually lead to my first post on SN (#57444).

0 sats \ 0 replies \ @snufon OP 9 Aug

deleted by author

100 sats \ 0 replies \ @0xIlmari 9 Aug

Hard forks are needed when you expand the consensus and start allowing things that were not allowed before. This is because it would break backward compatibility (noone is forced to upgrade their software).

Soft forks are when you narrow down the rules. This preserves backward compatibility.

It's okay if old nodes accept things we no longer allow (because we narrowed down the rules) because no block should be produced with these things anyway - remember that it's the miners who signal acceptance of a soft fork, not nodes.

0 sats \ 0 replies \ @TheMorningStar 9 Aug

This is a good video which made .e understood the same things you're asking here.

0 sats \ 0 replies \ @Octopus 8 Aug outlawed

stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.