UPDATED - Plot your transaction in the mempool

[bitmover]

I have been working in the last weeks in this project.

You can  see it here: https://bitcoindata.science/plot-your-transaction-in-mempool.html

What does it do?

You can plot your unconfirmed transaction ID in the text area to plot it in the mempool. This will give you a nice estimation about how far it is from being confirmed.

Alternatively, you can insert your transaction details manually and plot it in the mempool according to the fee per vbyte (fee rate) you decided to use.

For example, the transaction below paid a 10 sat/vbyte fee.
At that fee rate, there are currently 56 vMB of transactions ahead of yours. Theoretically, that  transaction will not get confirmed soon.


https://bitcoindata.science/plot-your-transaction-in-mempool.html


If the transaction fee rate is inside the next block virtual size, it will probably get confirmed in the next block.




How to use it?
Just insert your transaction ID or the transaction details if you didn't make your transaction yet. How many inputs, outputs, fee per vbyte and your address format.

When you hover the chart you can see the size of all transactions competing on your fee rate. This will help you to make your transaction as efficient as possible, according to your needs.


The tool also calculates your transaction virtual size and the total fee you are going to pay (in btc and usd).



A big thanks to @pooya87 and   @nc50lc who helped me with the calculations

I am open to suggestions, as I expect this community to use it.

[o_e_l_e_o]

My only real criticism is the graph is not particularly clear. The cut off lines between the fee rates need to be more visible, and it would be better to use different colors for different fee bands like on https://jochen-hoenicke.de/queue/#1,8h to make it easier to read. It would also be nice to still display the 1 Block cut off line at the bottom even when it is predicted that all the current unconfirmed transactions would be included in the next block.

I'd also include the line you have written above about the transaction size not being entirely accurate, particularly for P2SH/P2WSH addresses given the script size can be much larger than the size you use in your calculations.

Other than that, great work!

[TryNinja]

The "fee per byte" becomes very laggy when you change it (probably) because of the graph on the side re-rendering every time. If I type 3 digits, it freezes the page for a few seconds before responding to my keystrokes. I looks worse on Edge (based on Chrominium).

[bitmover]

My only real criticism is the graph is not particularly clear. The cut off lines between the fee rates need to be more visible, and it would be better to use different colors for different fee bands like on https://jochen-hoenicke.de/queue/#1,8h to make it easier to read.

This can be done, I will try to make a gradient color. But I particularly don't like those colorful graphics.
I will take a look at those colors.

It would also be nice to still display the 1 Block cut off line at the bottom even when it is predicted that all the current unconfirmed transactions would be included in the next block.

I am not sure if I got this. The theorical 1 MB size block should be at top, because transaction with higher fee rate are more likely to be included than those 1 sat/byte tx.

My graphic is making a line at 1 vMB (or 4 M Weight Units), which is the block size. From the top to the bottom.

I'd also include the line you have written above about the transaction size not being entirely accurate, particularly for P2SH/P2WSH addresses given the script size can be much larger than the size you use in your calculations.

The line is accurate. The line shows your transaction fee rate, not the transaction size. So, even if the size was wrong, the line would be the same.

However, The calculations are very precise for P2SH/P2WSH addresses.

I made tests here:

It is working very well now. Let's see those last P2SH transactions that I was having problems. Using blockstream as nc50lc suggested:

• https://blockstream.info/tx/d19e0257c3e37cb805d99a715568137c2553bbb25ee23d66ebcb1f4a2ac7d652
  1 P2SH input and 2ouput
  Calculates
  Transaction size: 247 bytes / 165 vbytes
  Transaction fees: 0.00027720 btc(3.03 usd)
  Real
  TRANSACTION FEES   0.00027556 BTC (166.8 sat/vB)
  SIZE   247 B
  VIRTUAL SIZE   166 vB
  
  
• https://blockstream.info/tx/4e313920ff45fb6be3866875c249e502159372afd46c081f320371114045619d
  Interesting case: 13 P2SH inputs , 1 P2SH output and 1 P2PKH output. Almost 100%
  Calculated
  Transaction size: 2299 bytes / 1254 vbytes
  Transaction fees: 0.00253308 btc
  
  Real
  TRANSACTION FEES   0.00254501 BTC (202.6 sat/vB)
  SIZE   2301 B
  VIRTUAL SIZE   1257 vB
  
  
• https://blockstream.info/tx/773f472b3806a9e8b51b9406a9080fb4ae015b28814f5ecb6ce6a3d5a47818e0?expand
  Looks like Bech32 outputs and P2SH outputs have both the same size. 100% match:
  
  3 P2SH inputs and 2 Bech32 outputs.
  Calculated
  Transaction size: 589 bytes / 346 vbytes
  Transaction cost: 0.00000346 btc
  
  Real
  TRANSACTION FEES   0.00000346 BTC
  SIZE   589 B
  VIRTUAL SIZE   346 vB
  
  

Summary:
1 - calculated 247 x real 247 https://blockstream.info/tx/d19e0257c3e37cb805d99a715568137c2553bbb25ee23d66ebcb1f4a2ac7d652
2 - calculated 1254 x real 1257 https://blockstream.info/tx/4e313920ff45fb6be3866875c249e502159372afd46c081f320371114045619d
3 - calculated 346 x real 346 https://blockstream.info/tx/773f472b3806a9e8b51b9406a9080fb4ae015b28814f5ecb6ce6a3d5a47818e0?expand

3 is a case of mixed formats and it is still 100% precise.

It is like 95% accurate or even more..

.

The "fee per byte" becomes very laggy when you change it (probably) because of the graph on the side re-rendering every time. If I type 3 digits, it freezes the page for a few seconds before responding to my keystrokes. I looks worse on Edge (based on Chrominium).

I will take a look at this, but I am not experiencing that.
It is very smooth here, specialluy in Edge.

Are you using Linux, Ios?
Edit: I looked more carefully and it is really re rendering. Maybe i didn't notice it laggy due to some config. But it is really lagging a bit in firefox. I will try to work on this.

[TryNinja]

Are you using Linux, Ios?
Edit: I looked more carefully and it is really re rendering. Maybe i didn't notice it laggy due to some config. But it is really lagging a bit in firefox. I will try to work on this.

I tried it on Windows.

If you don't find a better solution, you could make the graph only re-render 2-3 seconds after the last key is pressed. Something like this:

Code:

if(calcTimeout) {
  clearTimeout(calcTimeout);
  calcTimeout = null;
}
calcTimeout = setTimeout(calculate, 2000)

[pooya87]

excellent work.

it works well for a simplified calculation of transaction size and fees but it lacks advanced options which i think would be neat to add. you could either make this complicated and add those options or add a separate page and a selection on top to switch to advanced view which could be a bit more work for you.

here are some suggestions:

• both input and output have to have type. for example a P2WSH output type is 34 bytes whereas a P2WPKH is 22 bytes and it can affect the total transaction size specially if there are multiple outputs.
• it seems like you only support one specific P2SH while P2SH can be a wide variety of scripts (there is also 2 nested SegWit ones) which has to be addressed. a new combobox (dropdown) could be added to select from the most common redeem scripts: P2WPKH, multisig (2of3, 3of3 are most common i believe), locktimes with OP_CLTV and OP_CSV, P2WSH which would require another drop down to specify the redeem script used in that redeem script!, other which could ask the user to manually enter their redeem script size + signature size.
• if you can, draw a box around the chart on the right side representing the block with the total 4 MB weight that covers (from top) all transactions that could fit inside of it. if using a box is not an option, i guess a horizontal line would also be good.

[bitmover]

Thanks pooya
Those are really the limitations of this tool
I will probably add a button "advanced " and drop down more options for inputs/outputs and script types.

However, for now the priority will be to be able to paste the transaction Id and get it plotted in the graphic. I will do it in the next few days.

About your last suggestion,  to draw the line/box with the block size, it is already done.
Maybe when you looked the mempool was empty and you disnt see the line.

I marked from top to bottom 4M WU and 8M WU (1 and 2 block sizes) , showing all txs that can inside them in the mempool.
If the mempool is less than 4M WU, you cant see the line.

[ABCbits]

Great work, i like the visualization and information page (e.g.total fees/size) at one page since usually a website only show one of them (such as https://jochen-hoenicke.de/queue/#0,24h).

My only suggestion are :
1. Replace "P2SH" with "P2SH-SegWit" or "P2SH-P2WPKH" since there are many kinds of P2SH.
2. Add more black lines (e.g. 3 Blocks (12M Weight Units)) if previous black line haven't touch 1 sat/vbyte.

[notblox1]

Great work on this guys!
I have few small suggestions for improving the website and first one is cosmetic with adding dark theme switch.
It would also be good to add information when it is cheaper to send Bitcoins, this is usually weekend but many people don't know this, and maybe also add alerts when fees are higher, if this is not complicated to add.

[NeuroticFish]

1. I needed to also take a look at mempool.space to understand what I see on this tool page, so a bit of improvement is necessary, but I don't really know how to say what is needed
2. My confusion was also caused by a combination of 2 bugs:
2.1. If nothing is entered as fee, it still tries to show the place, and it in the top instead of bottom. Probably should warn/do nothing under 1 sat/vbyte.
2.2. If I put tx fee with decimals it doesn't show correctly the place. It behaves like described at [2.1] although decimals in fee/vbyte are allowed. My test was with 1.5

But overall it's an impressive and necessary tool page, well done!

[bitmover]

1. I needed to also take a look at mempool.space to understand what I see on this tool page, so a bit of improvement is necessary, but I don't really know how to say what is needed
2. My confusion was also caused by a combination of 2 bugs:
2.1. If nothing is entered as fee, it still tries to show the place, and it in the top instead of bottom. Probably should warn/do nothing under 1 sat/vbyte.
2.2. If I put tx fee with decimals it doesn't show correctly the place. It behaves like described at [2.1] although decimals in fee/vbyte are allowed. My test was with 1.5

But overall it's an impressive and necessary tool page, well done!

Thanks for pointing that out.
Definitely,  the decimals cannot be plot in the graphic. The graphic idea is to group fee rate by integers.

I will change the input box to get only integers. 1 sat vbyte is the minimum value accepted in bitcoin network. If you are sending a tx with lower than 1 sat vbyte it is probably 1 sat/ byte not virtual byte.

[NeuroticFish]

The graphic idea is to group fee rate by integers.

Sounds good, just may be good to write this (near the graph?) somewhere so people don't get surprised 

1 sat vbyte is the minimum value accepted in bitcoin network. If you are sending a tx with lower than 1 sat vbyte it is probably 1 sat/ byte not virtual byte.

I think that's the min value accepted by newer Bitcoin Core, however iirc really old ones were able to do even 0-fee.
It's clearly not feasible and the network will most certainly reject it today it if one builds such a transaction, still the UI should not accept it since some will enter such values. It may worth mentioning that in my case the box was completely empty (I just deleted an old value) when I've seen the error. So minimum 1 may not be enough, invalid values should be also made become 1.

[bitmover]

It's clearly not feasible and the network will most certainly reject it today it if one builds such a transaction, still the UI should not accept it since some will enter such values. It may worth mentioning that in my case the box was completely empty (I just deleted an old value) when I've seen the error. So minimum 1 may not be enough, invalid values should be also made become 1.

Thanks for pointing it out.
I changed the input fields, and now 0 values are not accepted for neither input/output and sat per byte fields.

you can still try to cheat and leave it blank to bug the graphic, but I won't change it now because I don't see why someone would try to bug the visualization...

1. Replace "P2SH" with "P2SH-SegWit" or "P2SH-P2WPKH" since there are many kinds of P2SH.
2. Add more black lines (e.g. 3 Blocks (12M Weight Units)) if previous black line haven't touch 1 sat/vbyte.

I implemented 2. Already working.

I will implement number 1, you are right about that. I will change the design a little and replace the P2SH with more detailed information.

My only real criticism is the graph is not particularly clear. The cut off lines between the fee rates need to be more visible, and it would be better to use different colors for different fee bands like on https://jochen-hoenicke.de/queue/#1,8h to make it easier to read.

I struggling in this color details, but I was able to do it now. There is now a gradient of colors from blue to purple. I am still struggling with color  variations, but it is better now.

Thanks for suggestions everyone. Still work in progress!

Edit: Added the text area to paste unconfirmed transaction iD. Now you can see your transaction in the mempool.

[NeuroticFish]

I changed the input fields, and now 0 values are not accepted for neither input/output and sat per byte fields.

you can still try to cheat and leave it blank to bug the graphic, but I won't change it now because I don't see why someone would try to bug the visualization...

That's correct. It looks very good now.
And I also like the new feature with the tx id. I am impressed.



I went to your tool page today and (since mempool is so busy) the first 3 blocks are not displayed "good enough" - hard to see what fees are there.
I don't know if it can be fixed in the same "image", you may need one more only for the top few blocks so one can use the tool to estimate the fee based on current mempool or see clearer where the tx actually is.

[bitmover]

I went to your tool page today and (since mempool is so busy) the first 3 blocks are not displayed "good enough" - hard to see what fees are there.
I don't know if it can be fixed in the same "image", you may need one more only for the top few blocks so one can use the tool to estimate the fee based on current mempool or see clearer where the tx actually is.

Thanks for pointing out that bugs.
When I made this tool the mempool was very different,  so I will need to make a few changes.

The best way to see the fees now is to click in the top of the image (about 200 sat/vbyte now as time of writing)
Are you able to see the fees now by clicking? I am using firefox in android .
You can also write your fee to plot it in the graphic. Worked here.

Remember that mempool varies a lot, and there is bi such thing as "the mempool".
This is the raw mempool data from one full node.
Each node has its mempool with different transactions. Maybe if you look at another mempool website you will see lower fees.

[NeuroticFish]

When I made this tool the mempool was very different,  so I will need to make a few changes.

The best way to see the fees now is to click in the top of the image (about 200 sat/vbyte now as time of writing)
Are you able to see the fees now by clicking?

Yes, the point was improvement, not bug fix. And it's just an idea, it's up to you if you see it worthy or not.
I am able to see a tx fee from block 1, ~248, but I cannot say it's the best fee or the last from block 1 (I can see one fee in block 1, one fee in block 2 and one fee in block 3 and in such small space you can't do much more).

What I meant was one more image, this time with fewer blocks (top 3?) but same height at the current image so more fee values can fit there like it is currently the 1-150 area. This would permit to see separately the top few blocks in a larger area hence a better "split" of the fees currently there.

[bitmover]

Big update:

Now you can plot your transaction in the mempool and see how much the transaction is far from the top of the mempool, in virtual megabytes (vMB).

There are three possible outcomes:

1 - Unconfirmed transaction fee rate is not inside the next block virtual size:


2- Unconfirmed transaction fee rate is inside the next block virtual size:


3- Transaction already confirmed:



Additionally, when you hover the chart you can see the size of all transactions above on your fee rate.



I am open to suggestions. Please tell me if you find any bugs.

I believe this tool can be useful in this moment when the network is congested

[erikoy]

Nice work OP, I hope to get use in that tool every time that I waited for confirmation by setting bitcoin transactions a smaller fee. I got bored sometimes not doing anything while doing the transactio so this could be a good way to find out the transaction and the same time to wait or to estimate time to be consume during the transaction. You guys are really something genius.

[hugeblack]

Instead of using a font with several colors, if you make it in a 3D stack it will make it easier to read the data and place updates.
Since we are talking about Plotting that contains a range of uncertainty, why should it not be in levels with (up & down) range rather than a value?
Is the data updated continuously or do I need to click on refresh button.

[bitmover]

Instead of using a font with several colors, if you make it in a 3D stack it will make it easier to read the data and place updates.

Thanks for your suggestions.

The graphic is basically 1D now. I could make it 2D, but I cannot visualize a way to make it better. Maybe a waterfall chart? Something like that?


The blue bars would be the fee rates and green the total mempool size. I can try to make something like that.

There is no waterfall chart in the chart library I am using, so it will be somewhat challenging to make it. But it may be useful and it is a good idea to add another dimension.

Since we are talking about Plotting that contains a range of uncertainty, why should it not be in levels with (up & down) range rather than a value?

I don't think there is  uncertainty.
The transaction fee paid for the transaction is certain, and their sizes are certain as well. Everything is registered in a sigened transaction, valided by full nodes and is in the mempool just waiting for confirmation.

The graphic is a raw mempool data, the transactions are just grouped by fee rates.

Is the data updated continuously or do I need to click on refresh button.

That's a good ideia. I will make it update every minute (the data from the API is updated once a minute)