Aug 20 - Aug 22, 2024
It highlights a key issue that current protocols automatically mine and relay transactions set with nLockTime
values either in the past or to a lower height, without considering the implications. This automatic process becomes a significant concern when addressing scenarios in which miners, who may oppose certain changes, could deliberately censor transactions representing those changes. The conversation extends beyond miner actions, acknowledging that users too might engage in censorship efforts against transactions carrying inscriptions or content they oppose.
Additionally, the dialogue seeks to clarify the meaning of "readiness" signaling within the context of including transactions in blocks. It questions whether "readiness" pertains to miners indicating their acceptance to process certain transactions or to users showing support for specific changes through their transaction practices. A critical point raised is the problematic nature of associating transaction inclusion with endorsement. This association does not accurately capture the intentions behind miners' actions, as they could manipulate transaction selection to artificially signal readiness, thereby affecting the perception of consensus or acceptance of changes within the Bitcoin ecosystem. This manipulation calls into question the reliability of using transaction inclusion as a metric for genuine community agreement or support for particular modifications, suggesting a need for caution against creating incentives for more sophisticated censorship tools within the network.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback