Bitcoin proposal : Delayed fee market

Abstract

In this article we propose a different fee system, with dynamically evolving fees. This variant of the currently used fee market is more efficient because it should minimize waste of bandwidth, storage and CPU while still providing an efficient anti spam mechanism and fee market for space. Furthermore, it is simpler to use for users, business and wallet providers.

Motivation and philosophy

Since the resources on the bitcoin network (bandwidth, CPU and storage) are limited, while the demand for those resources can grow indefinitely, we need a fee market to distribute these resources to the bitcoin users in the best way.

However the fee market has one main and major drawback : The uncertainty about whether or not an actual transaction will eventually be included in a block.

By setting up different fee levels, we can play around the probability of inclusion in the next block but we can never have a 100% certainty : There is a double variance of both block generation and of transactions being broadcast.

Centralized system usually offers a way to correctly predict whether an action (for example, sending a transaction) would be accepted or not. This property is extremely desirable, since uncertainty force users, softwares and merchants to manage around this uncertainty.

If the demand outweigh the system capacity, most centralized system will simply increase the cost of using it and queue the extra demand, providing an elegant mechanism to handle spikes.

Issues with the current fee market

The current fee market suffers from several issues :

Transactions can get stuck. Arguably this is the worst issue with the fee market. Your transaction can be stuck for two main reason : The first is that you used a software having a bad fee calculator, resulting in a badly estimated fee. In the future we can expect wallet software and this problem will go away.

The second reason for a stuck fee would be that there is a sudden increase in transaction activity, resulting in a backlog that can take days to clear until the transaction fees get lower, if it ever will. This phenomena is starting to happens and will happens more and more. The simple fact that transaction activity and block generation are both random guarantee it once the blocks are full.

Once your transaction is stuck in the nodes mempool, it gets really hard to remove for a novice user. Commonly proposed solutions includes double spending a transaction from another wallet, using special manual commands on a terminal, or simply waiting several days until the transaction has dropped from everyone mempool.

The currently proposed solution is to use Replace By Fee transactions (RBF) for senders, and Child Pay For Parent (CPFP) for recipient. Those solutions solve the “transaction stuck” issue but these solutions comes with their own set of issues.

RBF issues : RBF is simply a way to re-broadcast a previous transaction with a higher fee, thus preventing the “stuck transaction” issue. Unfortunately using RBF has many downside. First, it is much worse in term of user experience. The user needs to check that the fee was indeed insufficient and needs to be raised, even if wallet are set in a way where RBF is used automatically, it will confuse the user who might not find its original transaction.

It wastes network resources : When everyone will be using RBF, it is possible to imagine a scenario where everybody is bidding multiple times because the next block has been delayed. Since the network bandwidth is generally assumed to be the bottleneck for bitcoin scaling, this can be extremely detrimental.

Finally, it weakens inclusion prediction and renders bitcoin more complex for new users. If RBF is generalized for all transactions, it gives an easy way to double spend for attacker and completely kill 0 confirmations payments. Despite all those shortcomings, RBF is still extremely useful in the fee market.

There is another way to handle stuck transaction, this time on the side of the recipient.

Child pay for Parent : When a transaction get stuck, the recipient can create another transaction with the outputs of the initial transaction to pay an extra fee for the initial sender (hence the name).

CPFP brings many benefits. Once again it prevents a transaction from being stuck. It also does not allow any potential for double spend since the initial transaction is not replaced. Even better, it allow for merchant to reduce the double spend risk by providing a stronger incentive than an eventual double spend.

However, once again CPFP does not only create an extra transaction on the network but it also create an extra transaction on the blockchain, stored forever.

All those could be prevented by putting a “good enough fee”. However, there is no perfect fee prediction. Wallet providers need to implements complex algorithms to solve the problem of finding a optimal fee : A fee which will give good probability of inclusion in the next block while still being as low as possible.

This problem can not be solved perfectly : When there is 1 MB of space and 2 MB betting for it, 1 MB of transactions are bound to lose no matter what. This is not an uncommon situation as block are generated randomly.

Also this problem is also an arm race between wallet providers. If everyone has an algorithm tailored to beat you, you’ll lose. In a vacuum, the best algorithm to estimate fee would be one that estimate the fee the other would be using, and add one satoshi on top of it. There is no perfect solution to the fee prediction problem.

First proposal : Delayed fee market

Informally, the proposal would work like this (all values are given as examples, can be changed and should be further discussed before being agreed on)

If the average block limit wished for is 1 MB, the block size gets eight times as big, in this case 8 MB

Initial fee is set 100 satoshi per byte.

If a block contains any transaction for which the fee is inferior to the calculated current fee, the block is invalid

The accepted fee changes dynamically in time following this rule every 1000 blocks :

Every 1000 blocks, If (Average block size from (this block height -1000) to (this block height-5)) < 0.9 MB Then Fee for next 1000 blocks = 90% of previous fee / byte Else If (Average block size from (this block height -1000) to (this block height-5)) > 1.1 MB new fee / byte = 110% of previous fee / byte

Note : This proposal could also exist in a faster system, where for example the fee is incremented or decremented every 10 blocks. This would provides more resistance to attack but would be more complex to handle for the ecosystem (the fee might change rapidly all the time)

Remarks

Fees can still be set higher than the current target so a user can miss a block if its transaction propagate slower than predicted or if there is a network congestion. Also it can allow to create transaction that might be acceptable at a later time.

Not using the very last block for the average allow a user or software to correctly predict future fee even if he experience a network issue or if a very fast series of block are mined. It does not change the general proposal but makes it smoother by giving a 50 minutes times window to know what the fee would be.

It is interesting to remark that if we were already having an unlimited or much higher block limit, this change would be only be a soft fork !

Discussion

This proposal offers several advantage other the current fee market. It render the confirmation of transaction extremely predictable, since a transaction would either respect the current fee, or not. And based on that fee, be included or not since miners are rational and would try to include as much transaction as possible within the accepted maximum size.

Since the fee at which a transaction get accepted in a block is known, it renders the broadcast and mempool usage almost perfectly efficient : Only transactions with valid fees should be broadcasted and stored in the memory pools.

Thus it reduces the risk of double spend, render “zero conf” payment more secure, and reduce the risk of transaction hanging in the mempool for a long period of time. It reduce the risk of transaction dropping then being reused as an attack mechanism.

With this model, RBF and Child Pay for parent RBF should scarcely be needed since transactions not respecting the fee should not even be relayed and stored in mempool. It remove the extra network throughput needed for rebroadcasting unconfirmed transaction sitting in the mempool, which theoretically could be many times more than the number of non RBF transaction attempted if the RBF bidding model generalize and resource stay scarce.

There is no need to guess for optimal fee amount for wallet provider and less need to educate on potential unconfirmed transaction for users. It remove the need for extra interface and wallet mechanic for RBF.

Finally, it would keep the average block size identical and thus the blockchain size at the same wished size since the block size should oscillate around the targeted average.

Issue & potential Attacks

With this new model a major issue arise, and certainly several others that the authors did not think about.

Block size bloating & selfish mining : In bitcoin, since the fees included in a block are paid to the miner finding it, it essentially means that any transaction created by the miner itself is free.

Thus a miner can be tempted to fill his block with extra transactions, either because he thinks it will delay the block propagation (and thus gain a “head start” in mining the next block), or just because for some unclear reason he wants to attack the network. In the current bitcoin network since the blocks are currently limited to 1 MB it severely limit the scope of this attack : Propagating a 1 MB block is easy, and miners can even mine empty block if they did not already receive the block but just the header. Also with optimization such as compact & thin block, the transaction can be broadcasted pretty fast. Finally, if there is already more than 1 MB of transaction sitting in the mempool there is no empty space to bloat.

With a delayed fee market, there would be much “free room” in the block since the maximum would be much higher. Nothing prevents the miner from filling the block with its own transaction to attack the network, and also he might be tempted to “sell” the free space : If for example the current fee is 150 satoshi / byte, he can sell the space at for example 50 satoshi / byte and make a profit, killing the whole point of the delayed fee market and recreating a classical fee market just with much bigger block.

There is in our opinion only one way to solve all issues of selfish mining and block bloating : Averaging the fees paid over several block

Such a proposal could work like this :

Second proposal : Fee averaging

50% of the current block fees are for the miner (to keep a strong incentive to include transactions)

50% of the fees are split equally in the next 10 blocks.

This proposal eliminates a lot of the attack based on selfish mining. It suppress the underlying problem of many attacks which was that transactions are essentially free to create for miners.

Of course, the main problem of this evolution is that it would requires a hard fork of the bitcoin network.

We think this is a much needed upgrade to include in a hard fork : It prevents many attack scenario based on selfish mining, and prevents any bloating of the block by the miners.

About the authors

We love thinking about bitcoin and doing bitcoin research. If you want to help us spend more of my time on bitcoin research and less on our daily jobs, you can make a donation to :

13bsUuqZenNwF2tvm8HpnLBTSJwNebkCZJ

If you want to contact us, please use :

lespectrenoir42@gmail.com