Topic: Updating graph of fees for unconfirmed transactions (Read 2489 times)
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.
Looks like interesting times ahead for the mempool and fee situation.
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
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.
Thanks for adding the fee estimates.
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).
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?
Thanks for adding the fee estimates.
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).
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).
Stress test today: https://i.imgur.com/piPiRQ4.gif
With the floor removed:
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.
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.
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.
When is the next test?
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.
...
... 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 =
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.
The floor is now removed.
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.
...
... 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 =
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.
Wow. This is nice it will help alot. Thank you so much.. I will start following this link
Now a movie with a fixed 2MB scale Y-axis:
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. Donated
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.
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://bitcointalksearch.org/topic/m.11725683
-weex
"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://bitcointalksearch.org/topic/m.11725683
-weex
I don't know the fuck I'm looking at, but I like the geekiness of it.
Donated
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?
Jump to: