Posted by Greg Maxwell
May 2, 2025/06:29 UTC
The discussion initiates with a critical examination of the current restrictions on the use of OP_RETURN outputs in Bitcoin transactions, highlighting their counterproductive effects and inefficacy in preventing undesired practices. The critique extends to the broader issue of discrepancies between relay and mining policies within the Bitcoin network. Such mismatches are identified as sources of significant problems, notably increasing the latency of block propagation. This delay is detrimental, especially when a transaction is missed, as it can significantly increase transmission time, potentially tripling the per-hop delay if the missed transactions are larger than the TCP window. The impact on block propagation speed is further exacerbated by limitations in the existing prefill mechanism in compact blocks, which fails to ameliorate, and may even worsen, the situation by causing redundant transaction data transmission across nodes.
These propagation delays are not merely technical inconveniences; they have profound implications for the decentralization and economic dynamics of Bitcoin mining. Larger miners gain a disproportionate advantage over smaller ones due to these delays, irrespective of the direction of delay. This dynamic fosters mining centralization by enhancing the profitability of large miners at the expense of smaller operations, potentially driving them out of business. Moreover, the establishment of direct miner submission channels, while an attempt to mitigate delay issues, poses threats to Bitcoin's permissionless nature by disproportionately benefiting larger miners who can afford such infrastructure.
The dialogue further explores the consequences of restrictive relay policies on other aspects of the Bitcoin ecosystem, such as fee estimation accuracy. In response to these challenges, a principle is proposed: relay rules should encompass all transactions that are consistently mined. This approach does not imply endorsement of all transmitted transactions but acknowledges the practical reality of what is being included in blocks. It suggests a shift towards a policy that avoids the pitfalls associated with a relay policy more restrictive than mining practice.
Additionally, the inefficacy of existing rules against unwanted transaction types, such as address stuffing or direct miner submissions that bypass standard relay protocols, is acknowledged. Given the significant financial incentives for miners to include transactions that violate relay rules, the prospect of enhancing the effectiveness of these rules through adjustments is dismissed as implausible. The discussion underscores the inherent limitations of filtering mechanisms in a system designed to resist censorship and questions the utility of maintaining such filters.
In concluding thoughts, the conversation touches upon the potential role of user-configurable options (knobs) in adjusting relay policies. However, it casts doubt on their utility and appropriateness, suggesting that any such controls would be more relevant, and perhaps effective, if applied to mining policies rather than relay policies. This perspective stems from an understanding of the actual influence these policies have on transaction inclusion and network behavior, advocating for a more realistic alignment of software functionalities with operational realities within the Bitcoin 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