<p>Yes, soft forks do indeed tighten consensus rules. However, the restrictions usually happen for constructions that were previously useless, which means it doesn't interfere with existing features.</p>
<p>Specifically, SegWit restricted the rules for spending outputs with the format <code>OP_0 &lt;20 bytes&gt;</code> (P2WPKH) and <code>OP_0 &lt;32 bytes&gt;</code> (P2WSH). These outputs could previously be spent by anyone, which is why nobody used them. Similarly, Taproot restricted the rules for spending outputs with the format <code>OP_1 &lt;32 bytes&gt;</code> (P2TR, also called SegWit v1). In case of Taproot there was <a href="https://b10c.me/blog/007-spending-p2tr-pre-activation/" rel="noreferrer">one transaction</a> spending P2TR outputs before Taproot was activated, so an exception had to be put into the code when the deployment was <a href="https://github.com/bitcoin/bitcoin/pull/23536" rel="noreferrer">buried</a>.</p>

CC BY-SA 4.0
2023-06-15T18:44:19.943Z
Nit: segwit restricted spending of all `OP_0 <2 to 40 bytes>` (all but 20 and 32 bytes are unconditionally invalid), and also within P2SH. Arguably, it also added a restriction for other spends (they are not allowed to have a witness); see my answer.
Pieter Wuille
CC BY-SA 4.0
2023-06-15T18:54:40.440Z
@PieterWuille Does the restriction for other spends that a witness isn't allowed really count as a soft fork since according to the old rules witnesses don't exist?
Vojtěch Strnad
CC BY-SA 4.0
2023-06-15T19:02:59.917Z
Yeah perhaps, I think it may be matter of perspective. I see the P2P protocol change that allows relay of witnesses as separate from the validation rule changes. If you define "old spends" as "non-segwit output spends that don't have witnesses", then indeed nothing changes for old spends. But to be rigorous, I think it's worthwhile to be aware that non-segwit output spends with witnesses are possible in the P2P protocol, but violate segwit's consensus rules.
Pieter Wuille
CC BY-SA 4.0
2023-06-15T19:07:53.280Z
Interesting piece of P2P protocol trivia, thanks!
Vojtěch Strnad
CC BY-SA 4.0
2023-06-15T18:38:57.390Z
2023-06-15T18:38:57.390Z
Vojtěch Strnad
<p>Soft forks add rules that didn't previously exist which might be referred to as a &quot;tightening&quot; as opposed to a &quot;relaxing&quot; (a removal of rules). Upgraded nodes will check that these additional rules are met for every transaction and every block of transactions post the soft fork activation. Nodes that haven't upgraded won't check that these additional rules are met as they don't know that these additional rules are now being applied on the network. Hence they are effectively assuming (without knowing about them) that every transaction is meeting these additional rules and won't be able to identify a transaction that isn't meeting these rules as they aren't checking for them.</p>
<p>In the case that a block is mined with a transaction in it that doesn't meet these additional rules nodes that haven't upgraded would accept it as a valid block and upgraded nodes would reject it as an invalid block. However it wouldn't create a fork as the network would eventually agree on a blockchain that didn't include that block assuming a sufficient percentage of miners and full nodes have upgraded.</p>

CC BY-SA 4.0
2023-06-15T18:38:04.970Z
2023-06-15T18:48:49.323Z
2023-06-15T18:48:49.323Z
Michael Folkson
<blockquote>
<p>If this is true, then how are legacy transactions still present in the blockchain? Clearly, there are still plenty of transactions with non-segwit and non-taproot script types.</p>
</blockquote>
<p>I'll focus on Taproot first, because Segwit is somewhat more complicated.</p>
<p>The answer to your question is that following the Taproot softfork non-Taproot transactions are still present, because the Taproot softfork didn't affect the validity of non-Taproot transactions; they're all still valid.</p>
<p>What <em>did</em> change however is the validity of Taproot spends. Before the softfork, (what is now called) Taproot outputs (<code>OP_1 &lt;32 bytes&gt;</code>) were unencumbered, and thus spendable by anyone, without any signature. This didn't happen of course, because nobody was <em>creating</em> Taproot outputs that could be spent by this. But if they would have been created, they'd be stealable by anyone, including miners, at the time.</p>
<p>After the Taproot softfork, only Taproot spends that satisfy the Taproot consensus rules are valid anymore. Those that violate the (new) rules are no longer valid. This is the only thing that changed. You don't actually &quot;observe&quot; this tightening, because the only thing that changed is something that just didn't <em>apply</em> to any actually occurring pre-fork transactions.</p>
<p>For Segwit it's a bit more complicated, as it also introduced a new data field, where pre-Segwit transactions are just seen as having an empty such field. Segwit arguably introduced two separate rules:</p>
<ul>
<li>Segwit outputs (<code>OP_{0..16} &lt;2..40 bytes&gt;</code>), which were previously spendable without any signature or witness, can only be spent anymore if they satisfy the Segwit consensus rules (which look at witness data).</li>
<li>Spends of pre-segwit outputs cannot have a non-empty witness.</li>
</ul>
<p>While in this case there is arguably a rule that affects spends of old output transactions, it still doesn't result in an observable tightening, because pre-fork transactions just didn't have witness fields.</p>
<blockquote>
<p>I guess I just want to know why everybody says that updated nodes reject stuff from old nodes when that doesn’t seem true.</p>
</blockquote>
<p><em>Some</em> things, that were previously valid, are now no longer valid - and in practice, only things that nobody would use. That doesn't mean that <em>every old thing</em> that was previously valid is no longer valid.</p>

CC BY-SA 4.0
2023-06-15T18:36:15.263Z
2023-06-15T18:45:32.807Z
2023-06-15T18:45:32.807Z
Pieter Wuille
<p>I understand that a key element of a soft fork is that legacy nodes will accept transactions from updated nodes. This is essentially the whole point of a soft fork as opposed to a hard fork.</p>
<p>But researching soft forks you’ll find statements all the time like “soft forks tighten the rules” or that a soft fork means “old nodes still accept new node transactions but new nodes reject blocks/transactions from old nodes.”</p>
<p>If this is true, then how are legacy transactions still present in the blockchain? Clearly, there are still plenty of transactions with non-segwit and non-taproot script types.</p>
<p>Did segwit and taproot tighten the rules of the network and if so, how? I guess I just want to know why everybody says that updated nodes reject stuff from old nodes when that doesn’t seem true.</p>

<blockchain-fork><consensus><soft-fork>
Why does everyone say that soft forks restrict the existing ruleset?
Marco
# Why does everyone say that soft forks restrict the existing ruleset?

(Asked by: username_0 on 2023-06-15)

I understand that a key element of a soft fork is that legacy nodes will accept transactions from updated nodes. This is essentially the whole point of a soft fork as opposed to a hard fork.

But researching soft forks you’ll find statements all the time like “soft forks tighten the rules” or that a soft fork means “old nodes still accept new node transactions but new nodes reject blocks/transactions from old nodes.”

If this is true, then how are legacy transactions still present in the blockchain? Clearly, there are still plenty of transactions with non-segwit and non-taproot script types.

Did segwit and taproot tighten the rules of the network and if so, how? I guess I just want to know why everybody says that updated nodes reject stuff from old nodes when that doesn’t seem true.

**Tags:** blockchain-fork, consensus, soft-fork


---

## 3 answers

### Answer by username_2 on 2023-06-15. Score: 8 | Accepted answer

> If this is true, then how are legacy transactions still present in the blockchain? Clearly, there are still plenty of transactions with non-segwit and non-taproot script types.

I'll focus on Taproot first, because Segwit is somewhat more complicated.

The answer to your question is that following the Taproot softfork non-Taproot transactions are still present, because the Taproot softfork didn't affect the validity of non-Taproot transactions; they're all still valid.

What *did* change however is the validity of Taproot spends. Before the softfork, (what is now called) Taproot outputs (`OP_1 <32 bytes>`) were unencumbered, and thus spendable by anyone, without any signature. This didn't happen of course, because nobody was *creating* Taproot outputs that could be spent by this. But if they would have been created, they'd be stealable by anyone, including miners, at the time.

After the Taproot softfork, only Taproot spends that satisfy the Taproot consensus rules are valid anymore. Those that violate the (new) rules are no longer valid. This is the only thing that changed. You don't actually "observe" this tightening, because the only thing that changed is something that just didn't *apply* to any actually occurring pre-fork transactions.

For Segwit it's a bit more complicated, as it also introduced a new data field, where pre-Segwit transactions are just seen as having an empty such field. Segwit arguably introduced two separate rules:

* Segwit outputs (`OP_{0..16} <2..40 bytes>`), which were previously spendable without any signature or witness, can only be spent anymore if they satisfy the Segwit consensus rules (which look at witness data).
* Spends of pre-segwit outputs cannot have a non-empty witness.

While in this case there is arguably a rule that affects spends of old output transactions, it still doesn't result in an observable tightening, because pre-fork transactions just didn't have witness fields.

> I guess I just want to know why everybody says that updated nodes reject stuff from old nodes when that doesn’t seem true.

*Some* things, that were previously valid, are now no longer valid - and in practice, only things that nobody would use. That doesn't mean that *every old thing* that was previously valid is no longer valid.


---

### Answer by username_1 on 2023-06-15. Score: 5

Yes, soft forks do indeed tighten consensus rules. However, the restrictions usually happen for constructions that were previously useless, which means it doesn't interfere with existing features.

Specifically, SegWit restricted the rules for spending outputs with the format `OP_0 <20 bytes>` (P2WPKH) and `OP_0 <32 bytes>` (P2WSH). These outputs could previously be spent by anyone, which is why nobody used them. Similarly, Taproot restricted the rules for spending outputs with the format `OP_1 <32 bytes>` (P2TR, also called SegWit v1). In case of Taproot there was [one transaction](https://b10c.me/blog/007-spending-p2tr-pre-activation/) spending P2TR outputs before Taproot was activated, so an exception had to be put into the code when the deployment was [buried](https://github.com/bitcoin/bitcoin/pull/23536).

> **Comments:**
> **username_2**: Nit: segwit restricted spending of all `OP_0 <2 to 40 bytes>` (all but 20 and 32 bytes are unconditionally invalid), and also within P2SH. Arguably, it also added a restriction for other spends (they are not allowed to have a witness); see my answer.  
> **username_1**: @username_2 Does the restriction for other spends that a witness isn't allowed really count as a soft fork since according to the old rules witnesses don't exist?  
> **username_2**: Yeah perhaps, I think it may be matter of perspective. I see the P2P protocol change that allows relay of witnesses as separate from the validation rule changes. If you define "old spends" as "non-segwit output spends that don't have witnesses", then indeed nothing changes for old spends. But to be rigorous, I think it's worthwhile to be aware that non-segwit output spends with witnesses are possible in the P2P protocol, but violate segwit's consensus rules.  
> **username_1**: Interesting piece of P2P protocol trivia, thanks!  

---

### Answer by username_3 on 2023-06-15. Score: 2

Soft forks add rules that didn't previously exist which might be referred to as a "tightening" as opposed to a "relaxing" (a removal of rules). Upgraded nodes will check that these additional rules are met for every transaction and every block of transactions post the soft fork activation. Nodes that haven't upgraded won't check that these additional rules are met as they don't know that these additional rules are now being applied on the network. Hence they are effectively assuming (without knowing about them) that every transaction is meeting these additional rules and won't be able to identify a transaction that isn't meeting these rules as they aren't checking for them.

In the case that a block is mined with a transaction in it that doesn't meet these additional rules nodes that haven't upgraded would accept it as a valid block and upgraded nodes would reject it as an invalid block. However it wouldn't create a fork as the network would eventually agree on a blockchain that didn't include that block assuming a sufficient percentage of miners and full nodes have upgraded.


---

