Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-22 📝 Original message:On Fri, Feb 19, 2021 at ...
📅 Original date posted:2021-02-22
📝 Original message: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
📝 Original message: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