BIP - Fee structure and "fee adjustments"

[dree12]

Code:

BIP: Unnamed [codename: Fee]
Title: Fee Structure and Adjustments
Author: dree12 <no email associated>, Bitcointalk.org community <no email associated>
Status: Active
Type: Draft
Created: 2011-11-13

Fee Structure and Adjustments

This BIP is not secure at the moment. It is recommended that if considered, it should be installed on a merchant testnet to test for exploits. Currently, some exploits are identified but not patched. The feedback of forum users is well appreciated to identify which patches will and will not work.
Abstract
The Bitcoin network is operated and secured by miners. These miners mine because there is an incentive to do so. Currently, this incentive comes mainly from the block subsidy of 50 BTC. As block subsidy drops, however, it is still unknown whether fees will catch up. If Bitcoin is adopted widely, lowering fee rates will likely be very difficult. Bitcoin is designed so the miner will choose which transactions to accept and reject. This BIP proposes a method of providing a guideline accepted by both the client and the miner.
Motivation
To keep the Bitcoin network secure when the block subsidy approaches zero, the fee structure must be changed. A period of extensive economic activity may increase difficulty very fast, and then if followed by calm economic activity could destructively increase the time for block generation. Additionally, when economic activity is low the chance for a double-spend is greatly increased as miners turn idle due to lack of profit.

To achieve this, the fees must be kept relatively stable. It is impossible and unnessesary to react and anticipate the market ahead, and also unrealistic to restrict fees to a fixed amount. If the Bitcoin developers tried to set new fee tiers, old clients may take a long time to upgrade and the slow adoption will make many transactions take much more time to confirm.

Therefore, this BIP proposes adjusting a global "recommended fee multiplier" similar to difficulty and using the same concept. There will be little confusion between miners from this proposal.

Specification
This section is not well-researched and reflects no mathematical or cryptographic proof of security. Please help improve it by suggesting upgrades, changes, additions, or removals.

As previously outlines, this BIP will maintain a global "recommended fee multiplier" (abbreviated RFM). The current fee calculation method, or the future fee calculation method, is maintained. The client and miner's recommended fee will be calculated as such:

Code:

Fee = Raw Fee * RFM

This formula is used so that the RFM can be seen in a similar way to difficulty. To avoid issues with floating point calculations, clients and miners should calculate the RFM from an integer value maintained in the network, similar to difficulty's target. The Raw Fee can be at an arbitrary scale, as only the RFM needs to change.

Similar to difficulty adjustments, RFM adjusts to get closer to a target. The adjustment is exactly like difficulty adjustments, except instead of using the time between adjustments, the median fees included in a block is used. This means that if someone tries to put absurd fees into a block, there will not be an effect. The target fee amount should be made so that it will adjust block rewards as close to 51 BTC as possible. RFM adjustments, like difficulty adjustments, are capped by 400% and 25%.

To achieve the intended effect of preventing wild difficulty oscillations, the ideal time to adjust RFM is not coinciding with difficulty adjustments, but rather halfway between them. This ways, between two difficulty adjustments there will always be an RFM adjustment and vice versa. Since RFM regulates difficulty, this is ideal.

Rationale
An patch for this should be trivial and change no aspects of the protocol. The attack vector is extremely small, but clients and miners should offer an emergency responce button to switch back to the old system. If coodinated, this could easily defuse a fee-based attack.

As previously discussed, this method is only a recommendation. Miners and clients coordinating can easily switch back to the old system in case of an attack. This system should first be tested in a merchant testnet to reduce the risk. No money could be lost due to an attack. The worst possible case is that transaction fees either go so high the network nearly halts, or that some tx-spamming could be done due to a tiny fee. Both are temporary and arguable problems of Bitcoin itself, however attacks should be avoided at all costs.

Unlike manual fee-switching, this system gracefully blends into older client versions. There is also some confusing that may arise from clients wondering why fees keep changing, but this should be a rare event happening every two weeks.

A less evident feedback loop exists in this implemation. A sharp decrease in difficulty and an influx of mining power will cause the reRFM time to be much smaller, increasing the fee greatly because transaction volume was lower than before. The increased fee will then cause difficulty to go up again, as well as lower transaction volume, and therefore could be sustained for a while. This feedback loop is not likely to be very destructive, but could be prevented by adjusting RFM based on time rather than blocks.

A sharp increase in the fee is an additional way of entering this feedback loop. This time, it is much harder to stop. A solution is to give up on the fixed 51 BTC per block, and instead use the previous retarget period standard. This is a hybrid approach.

Possible Attacks
Another possible attack is without much incentive, but possible. If a miner controlling enough hash power and coins exists, they could produce transactions with a massive fee which will be payed to themself. The only true incentive for this is for their own transactions to be cheaper. Since the median fees are used to calculate RFM, more than 50% of the hashing power has to do this, which is unlikely.

The inverse of this attack is for a miner to not accept any fee transactions. This is not an attack: their impact is negliable and they are giving up income. This "attack" could be compared to a miner not mining to decrease difficulty.

Implemation and Adoption
This new fee structure can be adopted easily. As no change to the protocol is needed, all old clients will work fine. Miners do not need to immediately upgrade to serve the new clients. Relaying nodes upgrading to the new protocol is very important, however, which can be solved with BIP 14 and node selection. As long as a reasonable portion of miners and clients move over to the recommended fee system, the system will self-sustain.

Miners have an incentive to upgrade to this system because it guarentees a steady rate of income, rather than wild difficulty swings. As more miners migrate, clients and merchants will also have an incentive to upgrade because they will then be paying the minimum fee that will be accepted.

Credits
Thanks to DeathAndTaxes who provided the initial idea.

The following users of bitcointalk.org helped identify and fix possible attacks:

• BeeCee1

As this BIP has a thousand holes in it, thanks in advance to all users who help patch holes and suggest additions and modifications.

[1714114501]

1714114501

[1714114501]

1714114501

[1714114501]

1714114501

[BeeCee1]

Another possible attack is without much incentive, but possible. If a miner controlling enough hash power and coins exists, they could lower the fee by producing transactions with a massive fee which will be payed to themself. The only incentive for this is for their own transactions to be cheaper, but is clearly a dangerous attack. The only way I see to mitigate this attack is to change the protocol or only include transactions using the minimal fee. The second strategy seems ideal.

Explain why this is dangerous.  The way I see it a miner creates a transaction with a huge fee but doesn't propagate it unless/until they mine a block.   If they succeed they get lower fees, if they fail, they flush the transaction.  It seems like it has no downside.

If you only include transactions that have the minimal fee you eliminate the ability for someone to pay extra to get priority service (only really important if block sizes are nearing the maximum).  You also penalize transactions that are using a different algorithm that happens to be more generous, that seems like an odd thing to do.

[dree12]

Another possible attack is without much incentive, but possible. If a miner controlling enough hash power and coins exists, they could lower the fee by producing transactions with a massive fee which will be payed to themself. The only incentive for this is for their own transactions to be cheaper, but is clearly a dangerous attack. The only way I see to mitigate this attack is to change the protocol or only include transactions using the minimal fee. The second strategy seems ideal.

Explain why this is dangerous.  The way I see it a miner creates a transaction with a huge fee but doesn't propagate it unless/until they mine a block.   If they succeed they get lower fees, if they fail, they flush the transaction.  It seems like it has no downside.

If you only include transactions that have the minimal fee you eliminate the ability for someone to pay extra to get priority service (only really important if block sizes are nearing the maximum).  You also penalize transactions that are using a different algorithm that happens to be more generous, that seems like an odd thing to do.

Ah, right, I haven't noticed that. I meant only calculate the minimal fee in the fee adjustment, so that priority service can still be enabled. I modified the sections in question to use the median fee - although this may increase fees a little due to the median likely being on the low side.