Updating graph of fees for unconfirmed transactions

[PolarPoint]

I am looking at the chart now. The chart seems to show there are transactions paying 0.001btc/kb fees. Is that a 200 byte transaction with 0.0002 fee or someone is paying 0.001 fee for a 1kb transaction?

[1715586246]

1715586246

[1715586246]

1715586246

[1715586246]

1715586246

[findftp]

While writing a thing about fees, I wrote this sentence:

"There is no way to easily view the distribution of fees among transactions that
are waiting to be confirmed and" mid-sentence went off to build this:

http://bitcoinexchangerate.org/fees

Hope it helps everyone more easily visualize the fee situation. It'll update every 2 minutes as long as the bc.i API allows me or until I switch it over to running from local bitcoind data.

See an animation of this: https://bitcointalk.org/index.php?topic=1101202.msg11725683#msg11725683

-weex

I don't know the fuck I'm looking at, but I like the geekiness of it.
Donated

[weex]

I am looking at the chart now. The chart seems to show there are transactions paying 0.001btc/kb fees. Is that a 200 byte transaction with 0.0002 fee or someone is paying 0.001 fee for a 1kb transaction?

I have a floor of 1kb when calculating the fee per kb. So if the transaction is only 200 bytes and the fee is 0.1 mBTC, then that shows up as a the usual 0.1mBTC wall. If you see 0.001btc/kb then that could be a smaller transaction paying 0.001 BTC or if it's larger like 2kB then they are paying 0.002 BTC for that.

My reasoning for this floor has to do with the way wallets work. Bitcoin Core for example would pay its flat fee per kb for anything under a kilobyte. I guess I wanted to be able to see default fees in the graph but if there's a good practical argument on the spender's side, then I would change it. #1 is utility for users.

[weex]

I'm looking at, but I like the geekiness of it.
Donated

Thanks. It's kind of fun to think that your transaction contributed to the height in the curve on the graph until it was confirmed. I calculate about 0.2 of a pixel in height.

[weex]

Now a movie with a fixed 2MB scale Y-axis:

[thebenjamincode]

Wow. This is nice it will help alot. Thank you so much.. I will start following this link

[bitcoinfees]

I have a floor of 1kb when calculating the fee per kb.
...
... if there's a good practical argument on the spender's side, then I would change it. #1 is utility for users.

An argument for your consideration -

1. The purpose of the graph is to help users decide what fee rate to pay with their transaction.

2. The assumption is that miners (mostly) prioritize transactions by their fee rate, so by looking at the intersection of the graph with the line y = <typical max block size of 750-1000 kB>, we can gauge what fee rate is required to get into the next block, if it arrives now.

3. Miners do not, however, use a floor tx size of 1 kB when calculating fee rate (not in the reference implementation i.e. CreateNewBlock, nor is it economically rational - a miner should prioritize for example a 250 byte transaction over a 1000 byte one, if they are both paying the same fixed fee).

4. Therefore the data as presented now, with the floor size, is distorted with respect to its purpose in (1).

As a concrete example, consider a flood of 250 byte transactions, each paying a 0.1 mBTC fee. On the graph, it will show up as a fee rate of 0.1 mBTC / kB, because of the floor.

Next, consider a user who wants to jump ahead of the queue, so he views the graph and says, OK, I'll pay 0.2 mBTC per kB instead. His transaction is say 1 kB, so he pays a 0.2 mBTC fee.

However, in reality he would not have jumped ahead of the queue at all, because the fee rate of the flooded transactions (0.4 mBTC per 1000 bytes) is higher than that of his transaction.  So, he was not helped by the graph.

[weex]

I have a floor of 1kb when calculating the fee per kb.
...
... if there's a good practical argument on the spender's side, then I would change it. #1 is utility for users.

An argument for your consideration -

1. The purpose of the graph is to help users decide what fee rate to pay with their transaction.

2. The assumption is that miners (mostly) prioritize transactions by their fee rate, so by looking at the intersection of the graph with the line y = <typical max block size of 750-1000 kB>, we can gauge what fee rate is required to get into the next block, if it arrives now.

3. Miners do not, however, use a floor tx size of 1 kB when calculating fee rate (not in the reference implementation i.e. CreateNewBlock, nor is it economically rational - a miner should prioritize for example a 250 byte transaction over a 1000 byte one, if they are both paying the same fixed fee).

4. Therefore the data as presented now, with the floor size, is distorted with respect to its purpose in (1).

As a concrete example, consider a flood of 250 byte transactions, each paying a 0.1 mBTC fee. On the graph, it will show up as a fee rate of 0.1 mBTC / kB, because of the floor.

Next, consider a user who wants to jump ahead of the queue, so he views the graph and says, OK, I'll pay 0.2 mBTC per kB instead. His transaction is say 1 kB, so he pays a 0.2 mBTC fee.

However, in reality he would not have jumped ahead of the queue at all, because the fee rate of the flooded transactions (0.4 mBTC per 1000 bytes) is higher than that of his transaction.  So, he was not helped by the graph.

If the transaction is actually 1kb, then it's true you are thrown off worst by the floor. For people with smaller transactions, it's not the case but we also need to see wallets using the fee/kb properly taking into account the minTxRelayFee (0.00001 now). I guess the way to do that is for people to understand what fee/kb they are actually paying which as you note is what miners really care about.

The floor is now removed.

[Auxi]

When is the next test?

[scarsbergholden]

Subscribing to the thread, Great and on the breakdown and the graph, I'm this would help a lot of people have a better sight on the fee for the unconfirmed transactions.

[PolarPoint]

If you see 0.001btc/kb then that could be a smaller transaction paying 0.001 BTC or if it's larger like 2kB then they are paying 0.002 BTC for that.

Thanks for answering my question.

The function of the chart and stats are to help users decide what fee to include in transactions. It will be really helpful if you can study the unconfirmed transaction pool and include comments like these on the page:

0.00023456 btc/kb for a good chance to be included in the next block

0.0001 btc fee for a 400 byte transaction have a good chance to be included in 1.234 blocks
0.0001 btc fee for a 700 byte transaction have a good chance to be included in 2.345 blocks
0.0001 btc fee for a 1000 byte transaction have a good chance to be included in 3.456 blocks

You will need to study the last few blocks and the pool to get the estimates. It may be to be fine tuned later, but I think these estimates will be more helpful for newbies than the chart.

[weex]

If you see 0.001btc/kb then that could be a smaller transaction paying 0.001 BTC or if it's larger like 2kB then they are paying 0.002 BTC for that.

Thanks for answering my question.

The function of the chart and stats are to help users decide what fee to include in transactions. It will be really helpful if you can study the unconfirmed transaction pool and include comments like these on the page:

0.00023456 btc/kb for a good chance to be included in the next block

0.0001 btc fee for a 400 byte transaction have a good chance to be included in 1.234 blocks
0.0001 btc fee for a 700 byte transaction have a good chance to be included in 2.345 blocks
0.0001 btc fee for a 1000 byte transaction have a good chance to be included in 3.456 blocks

You will need to study the last few blocks and the pool to get the estimates. It may be to be fine tuned later, but I think these estimates will be more helpful for newbies than the chart.

Predictive estimates are hard but doable. I'm sure someone has figured out the best algo to use for it.

In the mean time, I've added a couple of threshold calculations to the text output.

Code:

Minimum fee/KB for 750KB block: 0.122549019608
Minimum fee/KB for 1MB block: 0.0796812749004

These are for if a block were found just after the last run of the script. Of course senders need to add a safety factor and multiply by their likely transaction size to figure out their fee.

[weex]

With the floor removed:

[weex]

Stress test today: https://i.imgur.com/piPiRQ4.gif

[PolarPoint]

Thanks for adding the fee estimates.

Code:

Minimum fee/KB for 750KB block: 0.446428571429
Minimum fee/KB for 1MB block: 0.387596899225

The stress test today has pumped minimum fees 3 fold. Your estimates have proved to be be accurate and helpful too. By looking at the fee estimates, we now know a 600 byte transaction will need 0.00026 btc fee for a good chance to confirm in the next block (if it's a 750k large block).

[weex]

Thanks for adding the fee estimates.

Code:

Minimum fee/KB for 750KB block: 0.446428571429
Minimum fee/KB for 1MB block: 0.387596899225

The stress test today has pumped minimum fees 3 fold. Your estimates have proved to be be accurate and helpful too. By looking at the fee estimates, we now know a 600 byte transaction will need 0.00026 btc fee for a good chance to confirm in the next block (if it's a 750k large block).

It was interesting that all that activity only increased effective fees for small transactions for a short period of time. What I've learned since is that core 0.10+ does its own fee estimate. Is it possible run that estimate without sending btc?

[dserrano5]

What I've learned since is that core 0.10+ does its own fee estimate. Is it possible run that estimate without sending btc?

RPC commands estimatefee and estimatepriority.

[weex]

What I've learned since is that core 0.10+ does its own fee estimate. Is it possible run that estimate without sending btc?

RPC commands estimatefee and estimatepriority.

Ok, added estimatefee for 1, 6, 12, and 24 blocks.

Code:

Total transactions: 4072  No fee: 65

All fees in mBTC
Bitcoinexchangerate.org Fee Estimates --------
Minimum fee/KB for 750KB block: 0.272603362108
Minimum fee/KB for 1MB block: 0.245098039216

Bitcoin Core Fee Estimates -------------------
Blocks ---- mBTC/KB
     1      0.7485
     6      0.29711
    12      0.19762
    24      0.01345

Statistics -----------------------------------
Minimum fee: 0.0
Maximum fee: 3.8
Average fee for payers: 0.16159594057
Median fee for payers: 0.1
Stdev of fee for payers: 0.207028360117
Total bytes: 2351637

[weex]

Looks like interesting times ahead for the mempool and fee situation.

[weex]

Updated to use a log scale since there are a ton of relay-level fee'd transactions. Also increased x scale to 2.0 mBTC max since fees are going up.