Published on: 2011-11-23T16:26:30+00:00
In a discussion on November 23, 2011, Andy Parkins proposed a potential solution to the issue of Bitcoin's network taking a long time to adapt when a large number of miners suddenly switch off. The proposal involved abandoning the concept of a target difficulty for blockchain nodes and instead having each node generate the most difficult block it can while simultaneously listening for "the most difficult block generated before time T." The value of T would be based on the block generation rate of 10 minutes.However, during the discussion, Jorge Timón raised a concern that miners could attempt to obtain more difficulty out of time and cheat their reported datetime (T). It is unclear whether this proposal was implemented or if any modifications were made to address the potential cheating issue.The author acknowledges that this proposed change would increase network traffic, but notes that there would be no need to broadcast the full block, only the header. This change would require a significant overhaul of the protocol and is considered one of many wishlist items for future improvements in the functionality and security of blockchain technology.The overall discussion highlights the ongoing efforts to improve the efficiency and adaptability of blockchain networks, showcasing the innovative ideas being considered within the Bitcoin community.In another discussion, Christian Decker expressed concerns about the "hardest block found in X minutes" scheme, where a miner would find an extremely hard block and keep it secret, building more blocks on top of it before announcing them all at once. If the rest of the network rejected this longer chain because the extremely hard block was not announced in a timely fashion, it could lead to a split in the network. Gavin Andresen responded by explaining that Bitcoin's difficulty target is used to compute chain difficulty, not the actual hashes found, which prevents this problem. He also mentioned a different method he proposed for dealing with large hash power drops on the testnet, although the details were not provided.The discussion questioned the location of the network clock, with the possibility of using the timestamps in the blockchain. The conversation continued with Timón expressing concern about miners cheating the system by hashing the block two minutes after it was supposed to be hashed and then sending it to other nodes. However, Parkins explained that this strategy is risky as the same window is available to everyone else, and their efforts may be wasted if their block is rejected by peers. The discussion further delved into the topic of the network clock, which is not part of the protocol but an individual miner's choice to accept or reject blocks based on the timestamp claimed. The clients currently use a community clock for compatibility, and miners are incentivized to use a similar time to what their peers are using to avoid having their blocks rejected under Parkins' proposed system.The overall discussion highlights the importance of a deterministic way to determine whether to accept or reject a block and the role of network clocks in the process. It addresses concerns about cheating the timestamp system and the potential for forks in the blockchain. Various proposals and ideas are presented, including setting an upper bound on block difficulty, using synchronized time windows, and selecting the hardest block. The conversation emphasizes the need to maintain the integrity and security of the Bitcoin network.
Updated on: 2023-08-01T02:41:07.829521+00:00