Yesterday's Taproot activation meeting on lockinontimeout (LOT)



Summary:

In an email conversation, Matt Corallo discussed the ban caused by invalid headers. Invalid headers due to MUST_SIGNAL rules are marked as BLOCK_RECENT_CONSENSUS_CHANGE, which does not directly result in a ban. If a lockinontimeout=true node requests compact blocks from a lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, it could result in a ban. Furthermore, nodes on both sides of a fork need to find each other to avoid competing with each other while catching up. This requirement is especially important when a chain where taproot is impossible to activate temporarily has more work. This same requirement may also be necessary for a signet feature that allows "optional reorgs" or mining blocks that will be reorganized out. The soon-to-be-stale blocks can be flagged so that the "don't-want-reorgs" nodes can easily ignore them, while the "I want to see reorgs!" nodes can connect with each other.


Updated on: 2023-05-21T00:47:28.218840+00:00