Difference between revisions of "Miner fees"
(Free transactions must be high-priority...) |
(Major rewrite; trying to write the page from a user-centered point of view, answering the questions they might have directly.) |
||
| Line 8: | Line 8: | ||
It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future. | It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future. | ||
| − | == | + | ==Reference Implementation== |
| − | + | The following sections describe the behavior of the [[Original Bitcoin client|reference implementation] as of version 0.7. Earlier versions treated fees differently, as do other popular implementations. | |
| − | + | ===Sending=== | |
| − | |||
| − | A transaction | + | A transaction will be sent without fees if these conditions are met: |
* It is smaller than 10 thousand bytes. | * It is smaller than 10 thousand bytes. | ||
* All outputs are 0.01 BTC or larger. | * All outputs are 0.01 BTC or larger. | ||
| − | * Its priority is large enough (see | + | * Its priority is large enough (see the Technical Info section below) |
| − | + | Otherwise, the reference implementation will round up the transaction size to the nearest thousand bytes and then add a fee of 0.0005 BTC per thousand bytes. | |
| + | Users may override the default 0.0005 BTC/kb fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee). | ||
| − | + | Note that a typical transaction is 500 bytes, so the typical transaction fee is 0.0005 BTC, regardless of the number of bitcoins sent. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | ===Including in Blocks=== |
| − | + | This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions. | |
| − | + | 27.000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block. | |
| − | |||
| − | + | Then transactions that pay a fee of at least 0.0005 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 250.000 bytes big. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough. | |
| − | + | ===Relaying=== | |
| − | The rules | + | The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, but a smaller value of 0.0001 BTC is used to determine whether or not a transaction is considered "Free". To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute. |
| − | |||
| − | |||
| − | |||
==Technical info== | ==Technical info== | ||
Revision as of 20:06, 25 January 2013
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many transactions are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.
The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.
Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.
It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.
Contents
Reference Implementation
The following sections describe the behavior of the [[Original Bitcoin client|reference implementation] as of version 0.7. Earlier versions treated fees differently, as do other popular implementations.
Sending
A transaction will be sent without fees if these conditions are met:
- It is smaller than 10 thousand bytes.
- All outputs are 0.01 BTC or larger.
- Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the nearest thousand bytes and then add a fee of 0.0005 BTC per thousand bytes. Users may override the default 0.0005 BTC/kb fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).
Note that a typical transaction is 500 bytes, so the typical transaction fee is 0.0005 BTC, regardless of the number of bitcoins sent.
Including in Blocks
This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.
27.000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.
Then transactions that pay a fee of at least 0.0005 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 250.000 bytes big.
The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.
Relaying
The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, but a smaller value of 0.0001 BTC is used to determine whether or not a transaction is considered "Free". To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.
Technical info
Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.
So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of
(500000000 * 10 + 200000000 * 3) / 500 = 11,800,000
