Bitcoin Forum

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.

Animations:
#1 https://bitcointalk.org/index.php?topic=1101202.msg11725683#msg11725683 (1kb floor)
#2 https://bitcointalk.org/index.php?topic=1101202.msg11732681#msg11732681 (1kb floor, fixed 2MB scale)
#3 https://bitcointalk.org/index.php?topic=1101202.msg11741136#msg11741136 (no fee floor)
#4 https://bitcointalk.org/index.php?topic=1101202.msg11756208#msg11756208 (June 30, 2015 stress test)

-weex

nice

Sweet. Could you include a statement showing the current minimum fee for automatic inclusion in the next available block? Something like, Current minimum for immediate processing: XXXX

Sure, I'll include a couple of them when I can get back to the code. One at 750KB and another at 950KB or what the max tends to actually be. Most of time as I've been testing it, the minimum fee hasn't really been calculable as the total  KB outstanding was less than 750KB.

I'm working on getting this running from a local bitcoind first as bc.i is not entirely likely to work in the case of massive transaction load...i.e. some sort of stress test.

Thanks, it looks great so far and I can definitely see myself using it often. Good work!

I didn't expect ppl are paying 0.000268533671518 BTC transaction fee to get transactions confirmed! If every one is paying larger than recommended fee, the miners will be happy! Nice chart! It gives us the rough fees we should pay to have the priority to get the the transaction included in the next block!

What I am concern is that if every ppl are paying high fee, what about the low value transaction? They cannot afford high fee and have to wait long time for the confirmation.

0.000268533671518 is the stdev(variation) for the fee people pay, not the minimum fee they pay, or the minimum). Some larger transactions require no fee, and other might take hours to confirm, and others pay more to make sure the transaction will be included in the next block or because they want spam the blockchain do dust transactions. Usually people pay 0.0001 BTC as transaction fee, and it is more than enough

Thanks this is a really good tool, and it will become important as the blocks start to fill up in the future to determine how much we need to include in our transaction fees.

/u/btcee99 on reddit brought up a good point since I linked to the code there: https://github.com/weex/bitcoin-fee-distribution

I set a floor of 1KB on the size when calculating fee/kb. I did this because of the way bitcoin core works now. You set a default fee like 0.0001 and it doesn't include a smaller fee just because your transaction was 226 bytes or whatever. Does anyone know roughly how different wallets handle calculating fees? Are there any that always multiply the transaction size by the a fee/kb rate? Is a 1kb floor assumed on any other code out there? Just thinking about loud. I'll research these questions later.

That is why a fork is needed for this because without a fork, everyone will need to pay higher fee to get it confirmed within the next block or that person will need to wait several hours. Also with paying high fee, this means bitcoin will not be suitable anymore for the smaller transaction like below 0.001 bitcoin

just awesome ...... continue it  :)

Running now from a local Bitcoin Core node so it updates every minute. The node was just started so will take time to catch up to bc.i's or even TradeBlock's unconfirmed transaction numbers.

If you see something interesting, please post the graph to imgur and link it.

I agree. I will start following this as well.

Could you maybe add time as another dimension or keep a certain amount of pictures? I found the analysis how these things change over time most interesting. This might make messy pictures though if its a landscape in 3d space.

I've started hanging onto the images and will create an animated gif once there are a few dozen of these things.

Edit: Here it is for the last 6-8 hours.
https://i.imgur.com/VehwOXt.gif

Bump for added animation.

the animation could be interesting if the scale on the left stayed fixed.

Awesome.


I suspect that the big changes are when blocks are found. Bitcoin creates nice sawtooth functions.

Nice work! Very interesting to see.


It would definately be better for your eyes and brain ;D

Started building a new one with 1200kb fixed max, then of course it started looking like there was going to be more so I changed it to 2000kb and what do you know it? A block was just found so it looks like nothing. Anyway, leaving it at 2000kb because it would suck if the 0.1mBTC level went above the max. Now, just to wait some hours.

As for the site, a sliding scale is best. Anyone who's running a node (--provider=bitcoind) and wants to play with this can have it running in a couple minutes.

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 don't know the fuck I'm looking at, but I like the geekiness of it.
Donated :)

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.

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.

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

https://i.imgur.com/cOjlano.gif

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

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.

When is the next test?

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.

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.


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.

With the floor removed:

https://i.imgur.com/aFS7k3m.gif

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

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).

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?

RPC commands estimatefee and estimatepriority.

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

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

https://i.imgur.com/NIpQg7P.png

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.