Published on: 2017-03-31T04:15:17+00:00
On March 30, 2017, a proposal was made to alter the difficulty scaling of block size. The proposal suggests that larger blocks would mean greater difficulty, but this doesn't scale linearly. Miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time, effectively increasing their profits. However, when such profitable fees aren't available, they have to reduce the block size. In other words, users pay miners to increase block size, or don't pay, which reduces it.The proposal suggests that the process could be simplified if a fee pool is created through softfork code instead of hardfork code. However, the effect will be partially reduced by the mining subsidy until it reaches parity with average total fees. Instead of altering the difficulty calculation, the proposal suggests altering the percentage of fees that the miner gets to claim versus what they have to donate to the pool based on the size of the block they generated. Larger blocks would mean a smaller percentage of fees. This is another way to pay for block size, and on average, miners that generate smaller blocks take a share of what otherwise would be part of the mining profits of those generating larger blocks. It is necessary to keep pieces of the section from above on expected blocksize calculation because the closer one is to the expected blocksize, the more they keep. Thus, adjustments need to be made according to usage.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.In a Bitcoin development mailing list, a proposal to expedite transactions by adding a second fee type was made. This would involve a specially labeled anyone-can-spend output with a defined "best-before" block number and a function describing the decline of the fee value for every future block. Miners can claim the full expedience fee plus a standard fee before block N, a reduced expedience fee plus standard fee between block N+1 and N+X, and only the standard fee after that. However, it was pointed out that OP_RETURN wouldn't work in this scenario and a new signature-check opcode would be required. Additionally, there is no real purpose to this proposal as miners already mine for fees as if it's their only chance to get the fee, so the fee effectively drops to 0 after one block. Another proposal that was softfork compatible was made for a fee pool to prevent miners from publishing their own "out of band fee" address and collecting all the fees directly.The author proposes a set of ideas to incentivize behavior improvement in Bitcoin. The first idea is called Expedience fees, which would allow transactions to have a second fee type that would grant miners the ability to claim a "best-before" block number for a given function that describes the decline of the fee value for every future block. When a transaction is processed late, the remainder of the expedience fee output is returned to the specified address among the inputs/outputs. The second idea is called Fee Pool, which is intended to act as a "buffer" to smooth out fee payments and prevent deliberate forking to steal fees. The third idea is Block size dependent difficulty scaling, which proposes that larger blocks mean greater difficulty, but it doesn't scale linearly. In order for a miner to profit from additional transactions, their fees must exceed the calculated cost of the resulting difficulty penalty to make it worth creating a larger block. The author believes that combining Expedience fees with Block size dependent difficulty scaling makes it even more effective.
Updated on: 2023-08-01T20:05:24.551728+00:00