Distributing low POW headers [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2013-07-28T20:07:34+00:00


Summary:

The email thread focuses on the possibility of distributing low proof-of-work (POW) block headers in the Bitcoin network to address issues related to forks and orphan blocks. The idea is to broadcast these headers approximately once every 9 seconds, with the aim of incentivizing miners to take them into account. It is suggested that distributing headers with 1/64th of the standard POW could help make forks less likely and prevent a fork from becoming the main chain if it is within 16 mini-confirms.There are concerns regarding the impact this change may have on miners' network connections and the potential economic implications. However, it is noted that adding fields to the header is challenging, so the distribution of headers could be implemented as a coinbase extra-nonce or by hashing an auxiliary header. By broadcasting all headers, clients would be able to count orphan blocks and measure their impact.Another suggestion discussed in the email thread involves setting a threshold relative to the height of the best block to determine when orphan blocks or headers should no longer be propagated further. This change should be compatible with the Peer-to-Peer (P2P) protocol and could be based on inventories.The email also mentions that Pieter Wuille is working on allowing Bitcoin to propagate and utilize pure block headers, which would be a step towards Simplified Payment Verification (SPV) and partial UTXO mode.In a separate email exchange, Peter Todd requests equations and data justifying the "magic constants" proposed in the distribution of headers. These include broadcasting headers once every nine seconds and giving them a value worth around four times as much as a full block. The goal is to create an incentive for miners to consider headers and ensure that a fork only becomes the main chain if it is within 16 mini-confirms.The proposal suggests changes to the current behavior of relaying blocks to peers and discusses the broadcast of headers even if they do not meet full POW. It is also proposed to display a warning on the client if a fork receives more than 15% of the hashing power.The proposal further suggests changes in the rules for distinguishing between forks and a BIP (Bitcoin Improvement Proposal). These changes involve broadcasting low POW headers, using header information to decide on the longest chain, and providing advantages to this approach. The distribution of low POW headers would be based on forwarding the first block header messages that have more than 1/64 of the standard POW requirements. Each link would receive extra credit for headers received, and the POW for a block would be calculated based on these credits. By following this rule, the top fork with the most hashing power would eventually catch up and win, incentivizing all miners to comply.To determine the longest chain, each link would receive extra credit for headers received, and miners would need to maintain a short-term view of the entire header tree. As long as miners keep headers for 30-40 blocks, they are likely to have all headers back to any reasonable fork point. This allows the top fork to be considered longer, even if it has two fewer blocks. If 75% of the miners follow this rule, the top fork will eventually prevail, encouraging the other 25% to comply. Even without complete agreement on headers received, the fork with the most hashing power will naturally gain the majority of headers, resolving ties quickly.Overall, the email thread discusses various proposals and considerations aimed at improving the Bitcoin network consensus, addressing issues related to forks, orphan blocks, and miner incentives. The suggested changes involve distributing low POW headers, modifying the behavior of relaying blocks, and establishing rules for distinguishing between forks. These proposals aim to enhance the stability and security of the Bitcoin network while maintaining compatibility with existing protocols and minimizing disruptions.


Updated on: 2023-08-01T05:23:49.451326+00:00