3

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.

3 Answers 3

8

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.

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

4
  • 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. Jun 15, 2023 at 18:44
  • @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? Jun 15, 2023 at 18:54
  • 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. Jun 15, 2023 at 19:02
  • Interesting piece of P2P protocol trivia, thanks! Jun 15, 2023 at 19:07
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.