Could Bitcoin Core leave the lockinontimeout parameter choice entirely to Bitcoin Core users and not set a default?

Question

There doesn't appear to be overwhelming consensus on the lockinontimeout (LOT) parameter for the Taproot BIP 8 activation mechanism. I know some would strongly argue against doing this but could Bitcoin Core release a version where users are forced to choose between setting LOT to true or false before running the software? Is this technically viable?

Answer 1

Matt Corallo and ZmnSCPxj answered this on the Bitcoin dev mailing list.

Matt Corallo stated:

Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles needed seem to be not worth it.

Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, testnet, and signet are treated), including its own separate datadir and the like.

ZmnSCPxj added:

Without implying anything else, this can be worked around by a user maintaining two datadirs and running two clients. This would have an "external" client running an LOT=X (where X is whatever the user prefers) and an "internal" client that is at most 0.21.0, which will not impose any LOT rules. The internal client then uses connect= directive to connect locally to the external client and connects only to that client, using it as a firewall. The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids). Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case. CPU usage is doubled, though. (the general idea came from gmax, just to be clear, though the below use is from me)

Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core ultimately ships with) on the external client based on the user preferences.

If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is whatever the user decided on), the user can decide to just destroy the external node and connect the internal node directly to the network (optionally upgrading the internal node to LOT=!U) as a way to "change their mind in view of the economy". The internal node will then follow the dominant chain.