Posted by ajtowns
Aug 20, 2025/05:26 UTC
The concept of enhancing blockchain efficiency and censorship resistance through improved block propagation methods is discussed, focusing on the maintenance of a small number of peers' top blocks in the mempool. The idea hinges on the premise that quick block propagation can be achieved even when transactions are filtered by a significant portion of the network. If a small subset of the network does not filter these transactions and forms a strongly connected subgraph, it significantly increases the likelihood that non-censoring transactions reach listening nodes ahead of time. This approach not only supports censorship resistance but also benefits spam-filtering mining nodes by reducing their orphan rate, and aids nodes that are not up-to-date with the latest policy or soft-fork changes.
To implement this, it's suggested that nodes continuously review updated templates from all peers rather than a select few, emphasizing the need to minimize bandwidth and computation required for processing these updates. Nodes would keep in memory a 2-3 block mempool tip last shared with others, plus one for each of a few selected peers they choose to remember. The deployment of a simple initial solution on the mainnet is advocated to gather data for refining this model. For instance, a GETTEMPLATE
request could be utilized to fetch a fresh template or a delta version based on a previously received template, facilitating efficient block relay between peers.
Compact blocks play a crucial role in this system due to their efficiency. The methodology behind compact blocks involves using short IDs for transactions, which were made possible by salting to keep the IDs sufficiently short without compromising efficiency. However, this raises considerations about computational burdens and potential security concerns, such as adversarial nodes creating transactions with matching shortIDs leading to reconstruction failures. Alternatives include continuing the use of 6-byte short IDs with a random seed for each template or employing a GETBLOCKTXIDS
step to manage missing transactions, aiming to balance efficiency with the need to avoid unnecessary retransmissions.
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