Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Anthony Towns <aj@erisian.com.au>]

On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
> It was pointed out to me that this discussion is largely moot as the
> software complexity for Bitcoin Core to ship an option like this is likely
> not practical/what people would wish to see.
> 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, 

I don't think this is true? With the current proposed bip8 code,
lockinontimeout=true will cause headers to be marked as invalid, and
won't process the block further. If a node running lockinontimeout=true
accepts the header, then it will apply the same consensus rules as a
lockinontimeout=false node.

I don't think an invalid header will be added to the block index at all,
so a node restart should always cleanly allow it to be reconsidered.

The test case in

https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8

tests that a node that had rejected a chain due to lockinontimeout=true
will reorg to that chain after being restarted as a byproduct of the way
it tests different cases (the nodes set a new startheight, but retain
their lockinontimeout settings).


(I think with the current bip8 code, if you switch from
lockinontimeout=false to lockinontimeout=true and the tip of the current
most work chain is after the timeoutheight and did not lockin, then you
will continue following that chain until a taproot-invalid transaction
is inclued, rather than immediately reorging to a shorter chain that
complies with the lockinontimeout=true rules)

Cheers,
aj