<blockquote>
<p>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.</p>
</blockquote>
<p>That's all correct.</p>
<blockquote>
<p>Would the latter consider the transaction valid?</p>
</blockquote>
<p>Yes. Non-segwit nodes will accept transactions with invalid segwit signatures.</p>
<blockquote>
<p>If yes, wouldn't this result in a chain split?</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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 <em>non-standard</em>, 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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-09-16T19:40:43.710Z
So is it fair to say that generally speaking, any soft fork will only remain a soft fork if the majority hash rate focuses on the new-rule-compliant chain, and that otherwise there would technically end up a divergence in node consensus?
Drazen Bjelovuk
CC BY-SA 4.0
2022-12-11T14:43:54.273Z
2022-12-11T18:17:55.173Z
2022-12-11T18:17:55.173Z
Pieter Wuille
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?</p>
</blockquote>
<p>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.</p>
<p>Definitions aren't always clear (e.g. re-org, chain split) but there wouldn't be a <strong>lasting</strong> 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.</p>

CC BY-SA 4.0
2022-12-11T09:50:56.663Z
Right. Isn't that's why they say a soft fork is when previously valid rules are made invalid?
Angelo
CC BY-SA 4.0
2022-12-11T10:07:27.177Z
@Angelo: A soft fork is the addition of consensus rules rather than the relaxation of consensus rules (hard fork). With a soft fork unupgraded nodes continue to follow the longest chain with most proof of work. With a hard fork unupgraded nodes reject the relaxation of the rules and are forked off the network when they encounter a "valid" relaxation of the rules
Michael Folkson
CC BY-SA 4.0
2022-12-11T09:05:02.007Z
2022-12-11T09:22:19.360Z
2022-12-11T09:22:19.360Z
Michael Folkson
<p>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.</p>
<p>Would the latter consider the transaction valid? If yes, wouldn't this result in a chain split?</p>

<segregated-witness><consensus><soft-fork><block-validity>
Do non-Segwit nodes reject Segwit transactions with invalid signature?
Angelo
# Do non-Segwit nodes reject Segwit transactions with invalid signature?

(Asked by: username_0 on 2022-12-11)

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?

**Tags:** segregated-witness, consensus, soft-fork, block-validity


---

## 2 answers

### Answer by username_1 on 2022-12-11. Score: 3

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

> **Comments:**
> **username_2**: So is it fair to say that generally speaking, any soft fork will only remain a soft fork if the majority hash rate focuses on the new-rule-compliant chain, and that otherwise there would technically end up a divergence in node consensus?  

---

### Answer by username_3 on 2022-12-11. Score: 3

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

> **Comments:**
> **username_0**: Right. Isn't that's why they say a soft fork is when previously valid rules are made invalid?  
> **username_3**: @username_0: A soft fork is the addition of consensus rules rather than the relaxation of consensus rules (hard fork). With a soft fork unupgraded nodes continue to follow the longest chain with most proof of work. With a hard fork unupgraded nodes reject the relaxation of the rules and are forked off the network when they encounter a "valid" relaxation of the rules  

---

