Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)



Summary:

In an email from Luke Dashjr on March 30th, 2017, he expressed his skepticism towards a proposal that suggested miners could potentially delay some transactions with lower fees in order to include them in the next block. He argued that miners always mine as if it's their only chance to get the fee, because if they don't, another miner will. Thus, after one block, the fee effectively drops to zero already. However, Dashjr proposed that with correctly configured incentives, making it more profitable to delay certain transactions with lower fees and including them in the next block would smooth out transaction inclusion. One suggestion was to change difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Dashjr also suggested tipping over at around a block size three times the standard block size, since the standard block size increases with continuous load after retargeting, the block size at which this happens also increases.Additionally, Dashjr noted that the fee pool does counteract the idea of delaying transactions with lower fees, as miners will still receive a share via the pool when there are fewer transactions available the next time they create a block, similar to insurance. Therefore, he questioned the incentive for a user to pay an individual miner the fee directly.


Updated on: 2023-06-11T23:02:41.961373+00:00