<p>Matt Corallo and ZmnSCPxj answered this on the Bitcoin dev mailing list.</p>
<p>Matt Corallo <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018450.html" rel="nofollow noreferrer">stated</a>:</p>
<blockquote>
<p>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.</p>
<p>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.</p>
</blockquote>
<p>ZmnSCPxj <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018455.html" rel="nofollow noreferrer">added</a>:</p>
<blockquote>
<p>Without implying anything else, this can be worked around by a user maintaining two <code>datadir</code>s and running two clients.
This would have an &quot;external&quot; client running an LOT=X (where X is whatever the user prefers) and an &quot;internal&quot; client that is at most 0.21.0, which will not impose any LOT rules.
The internal client then uses <code>connect=</code> 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)</p>
<p>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.</p>
<p>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 &quot;change their mind in view of the economy&quot;. The internal node
will then follow the dominant chain.</p>
</blockquote>

CC BY-SA 4.0
2021-02-20T12:54:33.880Z
2021-02-20T14:19:02.940Z
2021-02-20T14:19:02.940Z
Michael Folkson
<p>There <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html" rel="nofollow noreferrer">doesn't appear</a> to be overwhelming consensus on the lockinontimeout (LOT) parameter for the Taproot BIP 8 activation mechanism. I know <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018449.html" rel="nofollow noreferrer">some</a> would strongly argue against doing this but could Bitcoin Core release a version where users are <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018430.html" rel="nofollow noreferrer">forced</a> to choose between setting LOT to true or false before running the software? Is this technically viable?</p>

<soft-fork><taproot><activation-mechanism><bip8-version-bits>
Could Bitcoin Core leave the lockinontimeout parameter choice entirely to Bitcoin Core users and not set a default?
Michael Folkson
# Could Bitcoin Core leave the lockinontimeout parameter choice entirely to Bitcoin Core users and not set a default?

(Asked by: username_0 on 2021-02-20)

There [doesn't appear](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html) to be overwhelming consensus on the lockinontimeout (LOT) parameter for the Taproot BIP 8 activation mechanism. I know [some](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018449.html) would strongly argue against doing this but could Bitcoin Core release a version where users are [forced](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018430.html) to choose between setting LOT to true or false before running the software? Is this technically viable?

**Tags:** soft-fork, taproot, activation-mechanism, bip8-version-bits


---

## 1 answers

### Answer by username_0 on 2021-02-20. Score: 0 | Accepted answer

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

Matt Corallo [stated](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018450.html):

> 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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018455.html):

> Without implying anything else, this can be worked around by a user maintaining two `datadir`s 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.


---

