Add a line graph of "lowest fee to 1000kB / 900kB / 800kB"

[dabura667]

Currently the mempool in kB is a value with kB as the y axis and hovering the mouse let's you see how many cumulative kB consist of each fee level group + all the above.

I also think it would be good to have another separate graph which is a line, the y axis is satoshi per byte, and each plot would tell you "gathering all transactions from highest sat/byte rate to lowest, what is the sat/byte rate of the last transaction which fits within 1000kB?"

Maybe the graph could have 3-5 lines, each line being

"... 500kB"
"... 750kB"
"... 1000kB"
"... 2000kB"
"... 3000kB"

This way people can get a good idea of "ok, well if I aim for the fee of the 750kB line, and a block isn't found for a while, I might take 2 or 3 blocks, but if found in a reasonable time next block (etc etc)"

I use this site to get an eyeball for the actual fees I need to pay (bitcoind estimatefee is garbage, and most wallets still use it) and having those lines parallel each other will give me a better understanding of where to eyeball my fees.

[dabura667]

Although that logic I just mentioned might need to be fine tuned.

I'm just imagining what if the last tx to fit in 1000kB was 100 sat/byte and it just so happened there were 500 other 100 sat/byte transactions piling all the way up to 20000kB? Then aiming for 100 sat/byte would put you somewhere between 2-20 blocks away...

so maybe group all txes with the exact (to decimal points) same sat/byte rate into one big tx when counting...

[jhoenicke]

The database doesn't have the individual transactions, so I can't get the exact fee to the decimal point from it. It's a matter of database size. The database is now about 100 MB and grows 15 MB per month (106 numbers per minute). Storing all relevant information for individual transactions would probably mean 1 GB per month.

If you want it only for the current moment in time, it is of course possible to do it without the database. Just dump the current mempool and sort it by fee level.

I'm not sure if there is a good way to compute the fee. One problem is that exponential distribution of the blocks has a standard deviation of 10 minutes. Although they come on average every 10 minutes, they are usually much more than 10 minutes or much less than 10 minutes apart. Also the feed-back loop (a slow block leads to higher fees in fee estimators, which leads to much longer confirmation time for lower fees) make it hard to give a safe estimate for fast confirmations (so wallets tend to go 100-200 sat/byte over what is really necessary). I think if you want low fees and don't care so much about confirmation time, just make sure you are above any of the thick stripes (i.e. above 5 sat/byte, maybe also above 30 sat/byte at the moment). You may even try to take the week-day into account.

[dabura667]

No need to enter all the transaction's fee rates into DB, in the perl script just:

1. Create a 2D array with essentially [sat/byte, size, fee] for each entry
2. Sort the array descending index 0 (sat/byte)
3. Set a byte counter, and add up the size looping through each entry
4. If your byte size accumulator is equal or greater than the first byte size we want to graph (500kb etc.)
   a. starting with the currentIndex - 1 (the tx before pushing it over the limit) check if the transaction's sat/byte is equal to the next one (currentIndex) if so, move back to currentIndex - 2 etc. until you find the last tx that is not equal to the sat/byte of the currentIndex transaction.
   b. take the sat/byte value of the last tx that was not == to currentIndex.
   c. Continue from currentIndex + 1 and keep adding up cumulative byte size until you get to the 2nd byte size we want to graph.
5. Repeat until all of the byte sizes we want to graph are found.
6. If total size of mempool doesn't reach the target set it's value to 0.
7. The DB will only store $time, $size, and $feerate where feerate and size are arrays of the size of the number of targets you want.

my @kbAmountTargets=(500,750,1000,2000,3000);
my @txDataForSort=(   # (This obviously wouldn't be hard coded, but just to give an idea)
[230.448430493, 223, 51390],
...
);

[dabura667]

I would try my hand... but I have never written perl.

I tried though, and found many stackoverflow questions about sorting 2D arrays by the value of one of the indices of each entry. It seems like a one-liner.

After that, my method might not be the most efficient, but it gets the job done and I could maybe get it down if I learned perl, as my method seems pretty simple.

[dooglus]

The 600+ sat/B band is growing at the moment. It would be useful to be able to see a breakdown of that 600+ band. Currently I have no way of knowing whether 700 sat/B is enough to get into the top 1 MB of pending transactions or not. All I can see is that 600 sat/B is no longer enough.

[jhoenicke]

Added the bands to the main node a few hours ago and to the backup node now. I guess even 1000 sat/byte wasn't enough; more out-of-band fee payments than usual seemed to have happened. It seems to be over now; bitcoin cash difficulty update triggered and miners are mining Bitcoin again.

[dooglus]

I would also find it useful to have more resolution at the low end. During weekends the majority of the mempool is often in the smallest 0-5 band, so I don't know whether I need to pay 5/B or whether 2/B would do. Having separate bands for the 5 lowest fee rates would be good I think.