Can we experiment on Signet with multiple proposed soft forks whilst maintaining the ability of full nodes to validate the Signet chain?

Question

One of the goals of Signet is to test proposed soft forks before they are activated on mainnet. Not only does this mean proposed soft forks such as Taproot that at the time of writing (August 2020) are at an advanced stage (BIPs reviewed, PR under review in Bitcoin Core codebase, activation discussion started) but potentially other proposed soft forks that are at a less advanced stage. It is also worth noting that despite Taproot being at an advanced stage there has still been discussion on changing the BIP (340). With less advanced proposed soft forks they could change and be updated at multiple points before either being activated on mainnet or rejected entirely.

How will Signet allow for this experimentation and testing on proposed soft forks whilst maintaining the ability for full nodes to validate the Signet chain from genesis?

Answer 1

The way Signet will likely address this is to have two classes of Signet full nodes. The first class of Signet full nodes will stay on a stable Signet version and only update once the proposed soft fork is activated on mainnet. The second class of Signet full nodes will run experimental Signet versions and as a result will need to update every time a new proposed soft fork is added or a change to an existing proposed soft fork is added. If they don't they risk being forked off the Signet chain. This is similar to full nodes needing to update immediately assuming there were regular hard forks.

As an example (credit to AJ Towns for this explanation), imagine there were three classes of full node.

1. Doesn't enforce Taproot at all
2. Enforces the current Taproot rules from block 800
3. Enforces a future new set of Taproot rules from block 2400 (assuming R tie breaker changes)

Class 1 is able to validate the entire chain by ignoring the new soft fork restrictions in the same way as pre-SegWit versions of Bitcoin Core on mainnet can treat SegWit spends as anyone-can-spend. Once the proposed soft fork is activated on mainnet these Signet full nodes can safely upgrade to what would likely be a new stable and non-experimental Signet version.

Class 2 though does start enforcing Taproot rules from block 800. When those Taproot rules change at block 2400 unless the Class 2 nodes update they will start rejecting transactions following the new Taproot rules as they won't recognize them. They will evaluate those transactions according to the old Taproot rules and they won't be valid Taproot spends according to those old rules.

Therefore Class 2 Signet full nodes will need to upgrade every time there is a new experimental Signet version. Obviously this isn't ideal but it seems a reasonable trade-off given that the whole purpose of Signet is experimentation and testing with no real value on the line. If you can't test things for fear of hard forking Signet it isn't providing the testbed and staging ground that is required before changes are considered for mainnet with hundreds of billions of dollars on the line.