Posted by davidgumberg
May 22, 2025/02:56 UTC
The discussion revolves around the optimization of data prefilling in the context of TCP congestion control and its potential benefits for Bitcoin node communication. The premise is that by aligning the prefill amount with the TCP congestion window, it might be possible to avoid additional round trip times (RTTs) that slow down the communication between nodes. This approach is based on the assumption that the operating system's congestion control algorithm can accurately predict the maximum message size that can be sent without causing extra RTTs. It suggests that nodes with slower connections will automatically have smaller windows, thus reducing unnecessary prefill costs. This method could dynamically adjust to various connection speeds, effectively delegating the complexity of managing this adjustment to the expertise of kernel developers and the International Engineering Task Force (IETF).
To empirically assess the viability of this strategy, the author has initiated a branch (https://github.com/bitcoin/bitcoin/pull/32582) aimed at measuring the typical sizes of BLOCKTXN
fulfillments in compact blocks. Furthermore, gathering data on the congestion window sizes across different bitcoin nodes could provide valuable insights. If these windows are uniformly sized, then while compact block reconstruction failures might not be entirely eliminated, their frequency could be reduced through cautious prefilling without significantly increasing the cost. The observation from the author's node indicates that compact block messages typically are around 20kB in size, suggesting that an 800-byte prefill would leave ample overhead, potentially making this practice both efficient and economical.
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