Published on: 2013-11-15T10:52:40+00:00
The email thread among Bitcoin experts revolves around the cost of including transactions in blocks and how it benefits larger mining pools. Michael Gronager suggests that reducing network hops would decrease the cost of including transactions per kilobyte (kB). However, Peter Todd argues that this reduction is unlikely to occur and that large pools can easily connect with each other. He also advises smaller miners not to include transactions in their blocks if they want to remain competitive. The conversation concludes with a discussion on the reward system for miners and the importance of decentralization and resistance to a 51% attack.Peter Todd presents his calculation of the current fee being too small and argues against the need to set a maximum block size. He believes that the probability of a fork will naturally incentivize not letting blocks grow endlessly. Michael agrees with Todd's calculations and points out that the problem lies in Bitcoin's design itself. Regardless of block size or network speed, the current consensus protocol rewards larger mining pools with lower costs per kB to include transactions. Todd does not see rewarding economies of scale as a problem as long as the impact is not severe. The email includes links to other Bitcoin development topics.The fundamental issue at hand is that the current Bitcoin consensus protocol favors larger mining pools by granting them lower costs per kB to include transactions. This problem persists irrespective of block size or network speed. Allowing unlimited block size would exacerbate the problem by increasing fixed costs, while maintaining a 1MB block size indefinitely does not address the underlying issue. Being a larger miner confers significant advantages as they can charge lower fees for transactions, resulting in higher earnings. However, this creates a challenge for decentralization, as smaller miners lack the resources to match the high bandwidth and low-latency internet connections of larger pools. As a result, there are substantial differences in costs and perverse incentives to publish blocks to only a minority of hashing power.Michael Gronager introduces a framework for approximating minimal fees and optimal block size based on propagation time. He suggests that reducing propagation time would also reduce fees. Another parameter to consider is the time between blocks, which is currently closer to 400 than the ideal of 600 due to current hash acceleration. Mike Hearn proposes tracking and recording block propagation times, orphan stats per size bucket, and other network data to help users determine proper settings. Pieter Wuille corrects himself regarding C. Decker's paper, clarifying that it used measurements from blocks 20000-210000 between September and November 2012, before the release of version 0.8. Michael requests someone from academia to perform a full probabilistic analysis of his outlined model.A user in the Bitcoin development mailing list expresses the opinion that developers must first understand the tradeoff between propagation and fees before helping miners figure it out. They suggest developing a server that tracks and records block propagation times, fees passed up per block, orphan stats per size bucket, etc., as this would be immensely beneficial. Pieter Wuille corrects himself again, stating that C. Decker's paper actually used measurements from blocks 20000-210000 between September and November 2012, not blocks 180000-190000 as previously mentioned. The email also includes a link to November webinars for C, C++, Fortran developers to enhance application performance with scalable programming models and explore techniques for threading, error checking, porting, and tuning.In a discussion on the use of measurements for propagation delays in Bitcoin, Pieter Wuille corrects himself once more regarding the data used in C. Decker's paper. He clarifies that the actual measurements were taken from blocks 20000-210000, which occurred from September to November 2012, before the release of version 0.8 of bitcoind/bitcoin-qt.Michael Gronager discusses the possibility of estimating transaction fee size and optimal block size based on an article by Decker et al. Gronager determines that the propagation of a block is roughly proportional to its size, and slower propagation increases the risk of a fork. Miners must balance this risk with the opportunity to include more transactions and earn fees. Using equations, Gronager calculates the expected average earnings and concludes that the current fee is too small. He argues against the need for a maximum block size, as the probability of a fork naturally incentivizes not letting blocks grow infinitely. Gronager suggests two potential paths forward: raising the minimum fee or making transactions smaller. Broadcasting transactions in blocks solely as their hash could separate fee size from transaction size. According to Gronager's calculations, the current optimal block size is an empty block (without other transactions), and the current optimal transaction fee size should be 0.00076. Implementing a minimum fee of 0.00015 would lead to an optimal block size of 1083kB for a bounty of 25 and 2417kB for a bounty of 12.5.
Updated on: 2023-08-01T06:31:13.122812+00:00