BIP Draft: Flag day activation based on nLockTime signaling

The core issue lies in the potential misuse of nLockTime by miners and users alike, which could lead to increased censorship within the Bitcoin network. This is especially troubling when considering scenarios where miners may oppose certain changes, potentially leading to efforts aimed at censoring transactions that embody those changes. Furthermore, this scenario is not limited to miners; users could also partake in blocking the relay of specific transactions, such as those with content they disagree with, thereby fostering an environment conducive to the development of more sophisticated censorship tools.

The conversation also delves into the nuances of readiness signaling within the context of transaction inclusion, highlighting the problematic nature of equating transaction inclusion with miner or user endorsement. This association falsely attributes intentions to miners, who could manipulate this perception by selectively including or excluding transactions, thus undermining the reliability of transaction inclusion as a metric for consensus or acceptance of changes within the community.

A proposed solution to these challenges is outlined in a Bitcoin Improvement Proposal (BIP), which suggests an alternative activation method for soft forks that circumvents the issues associated with BIP 8 and BIP 9. This method involves broadcasting transactions with specific nLockTime values that signal support for different soft fork proposals. Miners then include these transactions in blocks to indicate readiness for the soft fork. After a three-month analysis period, the community can prepare for a flag day activation based on the observed transaction signals. This approach seeks to provide a clearer, manipulation-resistant mechanism for gauging support for protocol changes.

Moreover, the proposal acknowledges the possibility of transactions not being included in blocks due to various reasons. In such cases, it recommends that users replace the non-included transaction with another, specifying a different nLockTime, thereby ensuring their transaction eventually gets mined. This flexibility highlights a pragmatic approach to addressing the complexities of transaction inclusion, censorship, and soft fork activation within the Bitcoin network.

For further reading and technical details, the discussion and proposed implementations are available through the mailing list thread and the reference implementation links provided: Mailing list thread and Reference implementation for activation, Exclusion in relay or mining.