<p>The definition of a soft forking change is one such that every block which is valid to new nodes is also valid to old nodes. In other words, it is strictly restricting the set of valid blocks. Any change to block validity that does not have this property is a hard fork.</p>
<p>The reason for this distinction is that <em>if</em> a majority of the hashrate enforces the soft forking rules, the result will just be a single chain, because the chain produced by the majority in this case will be valid and accepted by old and new nodes alike.</p>
<p>Segregated witness (aka segwit, BIP141) is a soft forking change, because the only change is spends of segwit outputs without valid segwit signatures. These are valid to old nodes, but not to new nodes. However, any block valid to new nodes is still valid to old nodes, as such blocks will only contain valid legacy spends, and valid segwit spends.</p>

CC BY-SA 4.0
2024-10-16T06:13:19.420Z
“that every block which is valid to new nodes is also valid to old nodes“ What if old ones spend anyone can spend, its valid on their side, not valid on segwit
Sam Mitch
CC BY-SA 4.0
2024-10-16T06:38:57.460Z
Yes, that is correct, but not relevant. The *only* requirement for a softfork is that all blocks valid to new nodes are also valid to old nodes. A block containing an anyone-can-spend spend of a segwit output is not valid to new nodes, but that is irrelevant. The rule "if valid to new, then also valid to old"; it is **not** "if valid to old, then also valid to new".
Pieter Wuille
CC BY-SA 4.0
2024-10-16T06:47:21.553Z
By that logic, can’t we do the same with legacy base58 scripts, the ones that start with 1. Just not let them spend. Won’t be a “hard fork” but will be evil and dumb
Sam Mitch
CC BY-SA 4.0
2024-10-16T06:52:35.737Z
It being a soft fork by no means implies it is desirable; it still requires the ecosystem to adopt it, which hopefully wouldn't happen with detrimental changes. Soft forks are just safer to deploy, as they do not risk permanent forks if adopted by a majority hashrate, but that is it.
Pieter Wuille
CC BY-SA 4.0
2024-10-16T07:01:29.277Z
Ok, Thanks Peter
Sam Mitch
CC BY-SA 4.0
2024-10-21T15:40:06.700Z
The subsentence "the only change is spends of segwit outputs without valid segwit signatures" feels incomplete to me. Is it missing a word or part of the sentence?
Murch
CC BY-SA 4.0
2024-10-16T05:22:12.100Z
2024-10-21T15:39:25.283Z
2024-10-21T15:39:25.283Z
Pieter Wuille
<p>Imagine the network has only 20 miners.</p>
<p>Segwit was activated only when at least 95% of the miners signaled support, which means in our case 19 of the 20 miners have upgraded.</p>
<p>The remaining miner will start to see some strange tx on blocks, where anyone can spend.</p>
<p>If he spends one of those tx and then tries to include the spending tx in a new block, the other 19 will reject it, since for them it has an invalid tx. The immense majority of upgraded miners will prevent the chain from forking.</p>
<p>When requesting blocks to its peers, nodes send their software version.</p>
<p>When our sole miner asks for blocks to its peers, they know he didn’t upgrade to Segwit, so they send him the block without the witness, which must be smaller than 1 MB, thus making the block valid according to the old rules.</p>
<p>When an upgraded miner asks for a block to his peers, he receives the block with the witness, where the total must be less than 4 MB.</p>
<p>It’s a soft fork because old nodes consider new blocks valid.</p>

CC BY-SA 4.0
2024-10-16T05:20:34.863Z
2024-10-16T05:20:34.863Z
bordalix
<p>My question is a continuation of this one:</p>
<p><a href="https://bitcoin.stackexchange.com/questions/75107/why-non-segwit-nodes-do-not-reject-segwit-block-since-there-is-no-witness#75108">Why non-SegWit nodes do not reject SegWit block since there is no witness?</a></p>
<p>It says:</p>
<blockquote>
<p>“If so, what prevents it to be spent by anyone not the intended
recipient?</p>
<p>Most nodes (the ones who have updated) would reject this transaction.
Every miner would reject this transaction out of fear that their block
(and block reward) would be rejected.</p>
<p>You can fork off into a chain that spends those outputs though, if you
wanted.”</p>
</blockquote>
<p>Well, if by the old rules the transaction can be spent by anyone, and if pre-segwit node tries to spend it (lawfully), it will be rejected. So how is it a soft fork if old node blocks can be rejected based on nothing? Or definition of a hard fork means that old nodes will reject new node blocks?</p>

CC BY-SA 4.0
2024-10-21T15:42:54.400Z
Hi Sam, I updated the title of your question to summarize the content of the question. If you feel that I didn’t capture your intent correctly, please edit it further or roll back my change.
Murch
<segregated-witness><blockchain-fork><soft-fork>
How is segwit a softfork if old node blocks can be rejected?
Sam Mitch
# How is segwit a softfork if old node blocks can be rejected?

(Asked by: username_0 on 2024-10-16)

My question is a continuation of this one:

[Why non-SegWit nodes do not reject SegWit block since there is no witness?](https://bitcoin.stackexchange.com/questions/75107/why-non-segwit-nodes-do-not-reject-segwit-block-since-there-is-no-witness#75108)

It says:

> “If so, what prevents it to be spent by anyone not the intended
> recipient?
>
> Most nodes (the ones who have updated) would reject this transaction.
> Every miner would reject this transaction out of fear that their block
> (and block reward) would be rejected.
>
> You can fork off into a chain that spends those outputs though, if you
> wanted.”

Well, if by the old rules the transaction can be spent by anyone, and if pre-segwit node tries to spend it (lawfully), it will be rejected. So how is it a soft fork if old node blocks can be rejected based on nothing? Or definition of a hard fork means that old nodes will reject new node blocks?

**Tags:** segregated-witness, blockchain-fork, soft-fork

> **Comments:**
> **username_1**: Hi Sam, I updated the title of your question to summarize the content of the question. If you feel that I didn’t capture your intent correctly, please edit it further or roll back my change.  

---

## 2 answers

### Answer by username_2 on 2024-10-16. Score: 2

The definition of a soft forking change is one such that every block which is valid to new nodes is also valid to old nodes. In other words, it is strictly restricting the set of valid blocks. Any change to block validity that does not have this property is a hard fork.

The reason for this distinction is that *if* a majority of the hashrate enforces the soft forking rules, the result will just be a single chain, because the chain produced by the majority in this case will be valid and accepted by old and new nodes alike.

Segregated witness (aka segwit, BIP141) is a soft forking change, because the only change is spends of segwit outputs without valid segwit signatures. These are valid to old nodes, but not to new nodes. However, any block valid to new nodes is still valid to old nodes, as such blocks will only contain valid legacy spends, and valid segwit spends.

> **Comments:**
> **username_0**: “that every block which is valid to new nodes is also valid to old nodes“ What if old ones spend anyone can spend, its valid on their side, not valid on segwit  
> **username_2**: Yes, that is correct, but not relevant. The *only* requirement for a softfork is that all blocks valid to new nodes are also valid to old nodes. A block containing an anyone-can-spend spend of a segwit output is not valid to new nodes, but that is irrelevant. The rule "if valid to new, then also valid to old"; it is **not** "if valid to old, then also valid to new".  
> **username_0**: By that logic, can’t we do the same with legacy base58 scripts, the ones that start with 1. Just not let them spend. Won’t be a “hard fork” but will be evil and dumb  
> **username_2**: It being a soft fork by no means implies it is desirable; it still requires the ecosystem to adopt it, which hopefully wouldn't happen with detrimental changes. Soft forks are just safer to deploy, as they do not risk permanent forks if adopted by a majority hashrate, but that is it.  
> **username_0**: Ok, Thanks Peter  
> **username_1**: The subsentence "the only change is spends of segwit outputs without valid segwit signatures" feels incomplete to me. Is it missing a word or part of the sentence?  

---

### Answer by username_3 on 2024-10-16. Score: 0

Imagine the network has only 20 miners.

Segwit was activated only when at least 95% of the miners signaled support, which means in our case 19 of the 20 miners have upgraded.

The remaining miner will start to see some strange tx on blocks, where anyone can spend.

If he spends one of those tx and then tries to include the spending tx in a new block, the other 19 will reject it, since for them it has an invalid tx. The immense majority of upgraded miners will prevent the chain from forking.

When requesting blocks to its peers, nodes send their software version.

When our sole miner asks for blocks to its peers, they know he didn’t upgrade to Segwit, so they send him the block without the witness, which must be smaller than 1 MB, thus making the block valid according to the old rules.

When an upgraded miner asks for a block to his peers, he receives the block with the witness, where the total must be less than 4 MB.

It’s a soft fork because old nodes consider new blocks valid.


---

