Published on: 2015-06-01T20:02:31+00:00
In this discussion from 2015, Jim Phillips raises questions about the necessity of a hard limit on the block size in Bitcoin. While acknowledging the importance of maintaining consensus in the network, Phillips suggests that configurable settings could be used instead of a hard limit to address issues such as propagation difficulties and the need for a fee economy for miners.Phillips argues that the original purpose of the block size limit, to prevent spamming, is no longer a significant concern with the rise of ASIC mining. He proposes that allowing hardware limits to act as bottlenecks for scaling would be a more preferable approach than introducing an artificial bottleneck into the protocol that requires regular adjustment.The author further suggests that relay nodes should have the ability to configure their own limits on block size. This would prevent rogue miners from flooding the network with large blocks and potentially centralizing pools. By refusing to relay large blocks filled with nonsense or coming from miners known for producing bad blocks, relays can mitigate the risk of centralization and maintain a healthy network.The author also highlights that anonymizing networks like TOR are not designed to handle static IP traffic, which means larger miners using static IPs would not risk getting blacklisted by relays. Removing the 1 MB cap entirely could lead to further centralization of pools, as larger pools may create larger blocks that smaller pools cannot handle. This would force smaller pools out of the network and increase the percentage of network hashrate for the original pool operator.Furthermore, the author notes that larger blocks would result in fewer people willing to run full nodes and store all of the blockchain data. This could increase server costs for those running full nodes and make it impractical for individuals with home computers to keep up with the network. The author emphasizes the importance of finding a block size limit that strikes the right balance between resource restrictions and functional requirements.Ultimately, the author concludes that there currently does not exist a solution that adequately addresses all the tradeoffs involved in determining the block size limit. However, the author suggests that allowing relays to decide which blocks they propagate could mitigate potential attacks and limitations associated with block size. The author questions the necessity of a hard-coded limit that affects the entire network and poses ongoing challenges in the future, advocating for Bitcoin to grow naturally within the increasing limits of hardware.
Updated on: 2023-08-01T13:00:31.315660+00:00