Published on: 2017-12-13T00:12:45+00:00
In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered.
Updated on: 2023-08-01T21:30:19.625066+00:00