Changing the fees required for transactions to be relayed across the network and/or accepted by miners into their blocks requires care; policy mis-matches can result in users' transactions never confirming, either because they never reach a miner (they are not relayed) or because they are rejected by miners.
I have been working on simplifying the transaction fee rules for the 0.9 release; this document is intended to capture all of the details needed to make that transition as smoothly as possible.
The general idea is to make sure the transaction-generating code (the wallet code) is conservative, and generates transactions compatible with the previous version's rules. The relay and mining code is changed more aggressively, to anticipate future releases.
Base fee is: 10,000 satoshis per 1,000 bytes, transaction size rounded UP to the nearest 1,000 bytes (e.g. a 1,001 byte transaction requires a 20,000 satoshi fee). Can be changed with the -minrelaytxfee setting.
Transactions that meet the following criteria:
- Pay less than the base fee in fees
- Are less than 10,000 bytes large
- Do not have any outputs less than 0.01 XBT ("CENT rule")
... are considered "free transactions". They are rate-limited, then relayed.
There is one other relevant rule: transactions with very small outputs ("dust" -- around 5,000 satoshis, based on the -minrelaytxfee setting) are considered non-standard and are not relayed.
All of the relaying rules apply, because nodes will not mine transactions unless they relay them (and accept them into their memory pools).
27,000 bytes of the block (or -blockprioritysize) are filled with free transactions that have a priority greater than 57,600,000 (equal to a 250-byte transaction spending a 1 XBT input that is 1 day old).
The rest of the block (default -blockmaxsize : 250,000 bytes) is filled with transactions that pay at least 10,000 satoshis per 1,000 bytes ( can be changed with -mintxfee). Note that no rounding-up-to-1,000-bytes is done.
Remove the all-outputs-must-be-greater-than-CENT-to-qualify-as-free rule. bitcoin/bitcoin#3008 WHY: simplify the transaction creation / handling logic.
Increase the default -maxblocksize to 350,000 bytes. Increase the default space for high-priority transactions to 30,000 bytes. WHY: accomodate higher transaction volume, and to measure what percentage of hashing power simply goes along with defaults.
See bitcoin/bitcoin#3318...
Always pay a fee for transactions larger than 1,000 bytes. bitcoin/bitcoin#3008 WHY: create space for more free transactions.
The priority calculation is modified so spending extra inputs does not decrease priority. WHY: encourage cleaning up the UTXO set by spending dust.
Stop rounding up to the next 1,000 bytes when computing minimum-fees-needed-to-relay. WHY: match mining code.
New "reject" message is implemented, to tell peers that their transactions are not relayed due to insufficient fees. bitcoin/bitcoin#3185 WHY: band-aid, temporary fix until we figure out a better solution for SPV peers.
Require that miners set -mintxfee, -minblocksize, etc; refuse to mine if they do not. WHY: decentralize decisions about fees/block sizes/etc.
Use the new 'smartfee' code to determine whether a transaction has a high enough priority to get mined in the next few blocks. If it does, and priority-under-old-rules is greater than the old threshold, then send it without a fee.
If a transaction doesn't qualify as free: compute a minimum fee under the 0.8.6 relaying rules. And compute a minimum fee using the new "smartfee" estimation code. Use the larger of the two as the fee-to-be-paid.
The long-term goal is to get rid of all the hard-coded fee-related constants; let miners specify what they will mine, and let wallets figure out what the miners and mining.
Remove -minrelaytxfee. Implement a prioritized, memory-limited memory pool, and relay transactions that fit into the pool "right now" -- reject any that don't. (implementation TBD; maybe refuse to relay a transaction that has a priority and fee-per-kb less than the smallest priority/fee-per-kb transaction in the pool. And keep the pool below target size by evicting oldest transactions)
Remove the compute-under-old-rules code, and just use the new fee estimation code (with sanity check: refuse to create transactions that our memory pool would not relay).