Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
As far as I can tell, non-Segwit nodes receive anyone-can-spend transactions, and thus come with no signature to validate. If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.
Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?
If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.
Indeed. It would have to reach the miner so either sent to them directly or propagated to the miner by non-SegWit nodes. SegWit nodes would reject it and not propagate it.
Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?
Full nodes enforcing SegWit rules would reject a block with an invalid SegWit transaction in it as would miners enforcing SegWit rules. What would happen in your scenario is the miner would think they've successfully mined a block but full nodes enforcing SegWit rules would reject it and miners enforcing SegWit rules would refuse to mine blocks on top of it. So it can cause temporary confusion amongst full nodes not enforcing SegWit rules but the longest chain with most proof of work would end up not including that block and that is the chain that even the full nodes not enforcing SegWit rules would end up following.
Definitions aren't always clear (e.g. re-org, chain split) but there wouldn't be a lasting chain split unless a subset of miners refused to reject this block that didn't meet SegWit rules and continued to mine in perpetuity blocks on top of it. This would be a very costly endeavor as they would effectively be mining an altcoin and not what is considered Bitcoin.
As far as I can tell, non-Segwit nodes receive anyone-can-spend transactions, and thus come with no signature to validate. If a miner included a Segwit transaction to a block with invalid signature, it'd be rejected by Segwit nodes, but not by non-Segwit nodes.
That's all correct.
Would the latter consider the transaction valid?
Yes. Non-segwit nodes will accept transactions with invalid segwit signatures.
If yes, wouldn't this result in a chain split?
Temporary chain (1-2 blocks deep) splits happen all the time; it's what we have a blockchain and proof-of-work for to resolve. Having a sigificant hashrate (say, single-digit percentages) construct blocks that contain segwit-invalid transactions may result in slight increase in such temporary forks. Only pre-segwit nodes would notice these forks however, as post-segwit nodes will ignore the segwit-invalid blocks entirely.
The real concern would however be permanent splits. These can only occur if a majority hashrate is accepting these segwit-invalid blocks, because only those will build on top of it. As long as only a minority accepts such blocks, the majority will keep building on segwit-valid blocks, and thus such chains will in the end always overtake the segwit-invalid ones. Thus, even pre-segwit nodes will in the end only accept the segwit-valid chains. Post-segwit nodes again won't see or care about the segwit-invalid chains.
Note that constructing a block with segwit-invalid transactions (even by pre-segwit miners) requires deliberate effort from that miner. While segwit transactions (valid and invalid) are valid to pre-segwit nodes, they are non-standard, which means that such transactions won't make it to pre-segwit nodes' mempools and not be selected for inclusion in blocks. It's just that if they were to see such a transaction in a block, they'd consider it valid.
Lastly, all of the above applies to every softfork in modern history. Segwit was one example, but by now it's been so long ago (Aug 2017) that almost all deployed nodes (miners and others alike) enforce segwit's consensus rules, so the question has become moot. A more recent example is taproot (which activated in Nov 2021). Before that there were other examples like CLTV and CSV.
