Why does everyone say that soft forks restrict the existing ruleset?

Question

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.

Answer 1

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 2

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 spending P2TR outputs before Taproot was activated, so an exception had to be put into the code when the deployment was buried.

Answer 3

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.