You are here

Floating fees in Bitcoin Core 0.10

Submitted by jbrown on Mon, 02/16/2015 - 09:46

The latest release of the Bitcoin reference implementation has 2 new RPC commands related to fees: estimatepriority and estimatefee. They work by statistically observing the blockchain.

estimatepriority <nblocks>

Estimates the approximate priority a zero-fee transaction needs to begin confirmation within nblocks blocks.

The priority of a transaction can be calculated using the following formula:

priority = sum(input_value_in_base_units * input_age) / size_in_bytes

That is, the sum of the number of satoshis in each input multiplied by their age in blocks, divided my the total size of the transaction. The maximum size for a regular transaction can be determined from the number of inputs and outputs:

size_in_bytes = 149 * inputs + 34 * outputs + 10

The simplest transaction is defined as having 1 input and 2 outputs (227 bytes). In theory you could have just 1 output, but then you have no means to control how much of the input you are spending because there is no change address.

Previously the reference implementation would allow transactions into a block for free if they have a priority greater than 57,600,000. It also had to be smaller than 1,000 bytes and have all outputs 0.01 or larger. Other implementations and miners have different settings, so it is hard to know what priority is really required.

Now with the estimatepriority command it is possible to determine what priority is required on average to get a transaction into a block for free within nblocks. At the time of writing it is reporting 15,075,940,700 for nblocks = 1. This is 262 times greater than the previous reference implementation and perhaps a more realistic representation of the current behaviour of miners. This means to send 1 for free in the simplest transaction it would need to be 238 days old.

For it to confirm within 25 blocks it would need to be 12 days old. It's probably not worth endeavouring to not pay a fee on a transaction as for just $0.04 you are almost guaranteed to get the simplest transaction into the next block.

In fact, by default in 0.10 the reference Bitcoin wallet does not attempt to send zero-fee transactions.

estimatefee <nblocks>

Estimates the approximate fee per kilobyte needed for a transaction to begin confirmation within nblocks blocks.

I have added a transaction fees report page to my Coin Tools Drupal module. For all values of nblocks supported, it displays the average time for a transaction to confirm, the fee per kB, and the fee for the simplest transaction.

Below is a verbatim paste of the HTML table generated by Coin Tools at the time of writing:

Blocks Average time Fee per kB (bits) Smallest fee (bits)
1 8 min 23 sec 748.50 ≈ $0.1784 169.91 ≈ $0.0405
2 16 min 46 sec 456.62 ≈ $0.1088 103.65 ≈ $0.0247
3 25 min 10 sec 444.44 ≈ $0.1059 100.89 ≈ $0.0240
4 33 min 33 sec 444.44 ≈ $0.1059 100.89 ≈ $0.0240
5 41 min 57 sec 442.47 ≈ $0.1054 100.44 ≈ $0.0239
6 50 min 20 sec 442.47 ≈ $0.1054 100.44 ≈ $0.0239
7 58 min 43 sec 389.10 ≈ $0.0927 88.33 ≈ $0.0211
8 1 hour 7 min 389.10 ≈ $0.0927 88.33 ≈ $0.0211
9 1 hour 15 min 387.59 ≈ $0.0924 87.98 ≈ $0.0210
10 1 hour 23 min 387.59 ≈ $0.0924 87.98 ≈ $0.0210
11 1 hour 32 min 327.51 ≈ $0.0781 74.34 ≈ $0.0177
12 1 hour 40 min 268.09 ≈ $0.0639 60.86 ≈ $0.0145
13 1 hour 49 min 267.37 ≈ $0.0637 60.69 ≈ $0.0145
14 1 hour 57 min 229.35 ≈ $0.0547 52.06 ≈ $0.0124
15 2 hours 5 min 228.31 ≈ $0.0544 51.83 ≈ $0.0124
16 2 hours 14 min 192.67 ≈ $0.0459 43.74 ≈ $0.0104
17 2 hours 22 min 162.07 ≈ $0.0386 36.79 ≈ $0.0088
18 2 hours 31 min 134.58 ≈ $0.0321 30.55 ≈ $0.0073
19 2 hours 39 min 111.42 ≈ $0.0266 25.29 ≈ $0.0060
20 2 hours 47 min 103.24 ≈ $0.0246 23.44 ≈ $0.0056
21 2 hours 56 min 74.96 ≈ $0.0179 17.02 ≈ $0.0041
22 3 hours 4 min 44.44 ≈ $0.0106 10.09 ≈ $0.0024
23 3 hours 12 min 29.85 ≈ $0.0071 6.78 ≈ $0.0016
24 3 hours 21 min 29.67 ≈ $0.0071 6.74 ≈ $0.0016
25 3 hours 29 min 19.14 ≈ $0.0046 4.34 ≈ $0.0010

https://blog.bitcoinfoundation.org/floating-fees-for-0-10/

Comments

>Now with the estimatepriority command it is possible to determine what priority is required on average to get a transaction into a block for free within nblocks.

Sorry if you actually answered the question and I actually missed:

What is the data basis for this average calculation? The entire Blockchain history? Today's history? etc.

Maybe I misunderstand the calculation performed there, but it seems to me there is no way around this estimation being *on a certain segment of the data*, with all the implications that come from it: if on the entire history, possibly including many outdated data points, if only based on most recent history, possibly fluctuating too much.

Do you happen to know how it works?

Add new comment