Topic: BitcoinQueue.com ⏳ ★ Real-time Queue Charts 📈 (Read 2393 times)

Sorry about letting you down for so long, the site is coming back to life soon!

I am running a dedicated full node for collection purposes now, so more reliability is to be expected.

Thanks for your interest, stay tuned...

https://blockchain.info/unconfirmed-transactions  

I think it looks good and see the many queues transaction for immediate confirmed

At the moment, if you need quick settlement you'd better triple the usual fee.

You should go at least >100 satoshi / byte if you want to make it a matter of hours.

Damn that doesn't look good especially for businesses

The queue has returned, and it's uglier than before! It's been hovering over 60k almost for the last 2 days

https://www.bitcoinqueue.com/details/



https://www.bitcoinqueue.com/details/

We currently see the highest peak on the graph since the site started several months ago!



https://www.bitcoinqueue.com/

Sorry that I missed your last post until now. Yes, I can confirm that BitcoinQueue.com is using blockchain.info transaction feed until now, partly because running a full Bitcoin node on my VPS would be costly, and also because among all centralized sources I could choose from, it seems the most sensible and reliable to pick.

It could change in the future, the idea would be to merge several sources into the incoming feed.

Again we can see unconfirmed transaction build-ups occurring on a regular basis. Not much has changed in the transaction fee landscape for the last three months, which is partly why no significant update was done until now.



I am now resuming development of BitcoinQueue.com to include a very useful feature in my opinion, which is individual unconfirmed transaction lookup and statistics. That means you can fill in the transaction ID, and see where your transaction sits in the queue, the probability that it will be included in the next blocks, and other useful statistics.

The gap with bitcoinfees.21 does not seem to be closing.
Every price bracket is different?
(i.e. 21-30 sat, 2650 tx pending Bitcoinqueue.com but only about 200 tx pending on Bitcoinfees.21)

Bitcoinqueue's total transactions do seem to tally with Blockchain.info
Therefore, Blockchain.info mempool does not tally with Bitcoinfees.21 mempool either.
I had suspected Blockchain.info did not count zero fee transactions, but as Bitcoinqueue (taking from Blockchain.info) does have "some" zero fee, that does not seem to be the case.

Can you explain this difference?
(do you consider Bitcoinqueue "accurate" for seeing "the mempool", will it be "more accurate" if you tap directly into the network?)
Can fees be accurately calculated if "the mempool" is a nonspecific thing, different to each site?
(Blockchain.info are not publicly predicting fees of course, but do show "total" unconfirmed. Seems quite meaningless without scope)

Sorry if I'm struggling to express my issue simply and clearly. 

[UPDATE]

10 donators already, thank you very much

Many new features will be added before next week, including the following:

• Block information with evolution of stats with each block (requested feature)
• More details and statistical analysis of the mempool/unconfirmed queue
• Live overview with totals and average wait time

Stay tuned!

[UPDATE]

Now live table data is coming up, get a sneak peak here

http://www.bitcoinqueue.com/live.html

First, we need to agree that 72h is the comparison metric. This was only recently changed on bitcoinqueue.com (it was initially 4h, then 8h), i.e. on Friday afternoon (UTC). Then during the week-end, we lost almost 24h of data because the tx feed had died.

The reason of the failure is the following: My tx feed is using a websocket client that seems to keep the entire stream in memory until the websocket is disconnected. That caused the process to use always more RAM, first filling the swap and then killed by the kernel to preserve the system. Unfortunately, although all exceptions were caught within the program, there was nothing at that moment to restart the process.

The collection process is now protected by a shell (literally) to restart the process automatically, and I will update the process itself to stop after a 100,000 tx or so to work around the memory "leak" (stream as buffer, not clearing up). It will be easier than modifying the websocket client libraries, which is an external package (not my work).

So, the process was restarted this morning around 9.30am (UTC). If you add 72 hours to this, it means that it will only be since Wednesday that we will be able to compare bitcoinqueue.com data with bitcoinfees.21 and it will then be interesting if the gap has closed by then as it should be the cast.

Eventually, the tx data will be fed from my own internal source, but I have to work on this first: either run a full Bitcoin Core instance to feed the unconfirmed transactions, or tap directly into the network, but I have to make sure that tx are decoded the same was as Bitcoin Core would

The donations and continued interest over the project gives me more enthusiasm to develop the project further, of course

PS: our data now seems to be coherent with blockchain.info, which is temporarily used as feed source.

Hey Matt, me again!

Cool, I am only motivated by actually wanting to see this work.
I don't want to jump in too soon, but I have another question.

Why are there only about 800 transactions under <10 sat on your chart, and about 3700 transactions in total.
On bitcoin.info there are about 4100 transactions in total,
and on bitcoinfees.21 there are about 3500 transactions >10 sat, and 43000 10 sat and under?

You're not annoying me at all, your feedback is very much appreciated, thanks!

Of course, I'm still in the beta / experimental phase, but as you said, I'm getting there.

A huge and nasty bug has just been busted in the detail view, i.e. the >100 fee class wasn't summed up correctly (it was giving the average for all classes above 100 instead of summing them into one "more than" class).

Now the simple view and detailed view are reconciled. Phew

I thought something was wrong. Keep working, you'll get there!
Looking better again now, with a quick glance. (it was flat lining, not now)

I'll clear off if i'm annoying you now? 

The collection process (tx feed) was killed by the kernel over last night

I will be adding monitoring soon, stats have started rebuilding around 9am UTC this Sunday.

The sampling method, used for intervals 8h and higher, has been changed for the detailed view, and will be used for the simple view soon.

Stay tuned!

Ah, /details/..  I was missing something!

Good job. this will surely be a good info source after halving.

http://www.bitcoinqueue.com/details/

Am I missing something (or are you)?

I That live? I don't see it, just the old version.

[MAJOR UPGRADE]

Detailed stats are finally available!

The current chart include zero-fees in "<10 s/B" area.

[LATEST NEWS]

Please note that data may be inaccurate as the engine was heavily improved over the last 24h, and needed several restarts.
From noon UTC today, transactions will stay in the queue for 3 days, i.e. 72 hours, mempool default.

All queue data has now been logged since around noon (UTC), i.e. 8 hours ago at time of writing.

Since about 30 minutes ago, a new version of the graphs is building, with fee groups of 10 satoshi increments, i.e.

Group 0: 0 (strictly zero fee)
Group 10: 0.xx -> 10
Group 20: 10.xx -> 20
Group 30: 20.xx -> 30
...
Group n: n.xx -> (n+10)

And the new area charts will show every group

Preview coming soon

Matt,

Your chart has "fees <10 sat/byte". Does that include 0 sat/byte, or is it 1 - 9?
Your chart in no way resembles 21fees figure in this <10 category. What am I missing?

(infact, none of it tally's with bitcoin21fees.co? what am i missing  )

 

[UPDATE] The engine has been completely rewritten to fit the ever-growing queue!

Transactions will be kept for 72h from now on, matching the default mempool retention of Bitcoin Core.

Sorry about the disruption in the charts, the queue had to be rebuilt from scratch. Another good news is that every transaction is stored separately into the database from now on, allowing for retroactive statistics to be (re)built in the future.

Very good job, OP, and good to have this in place ahead of the turmoil that will follow halving.

[UPDATE] The new transaction timeout has been set to 24 hours (instead of 8 hours previously)

Thank you all

In the next few days, I will be adding breakdown tables and total tx fees per fee class in the data very soon, as well as more information about the average/median tx inclusion time in a block. I need to upgrade my backend first though.

Interesting website, I was looking for something keeping track of such stats over time but couldn't find anything. Good job OP.

Good job 

I have checked bitcoinfees.21.co and upon first look, the >=50 s/B group should (now) be correct on the charts, i.e. the teal colored area in the chart, currently about 8k out of about 20k in the queue.

Please also note that I had to transition data stream from an older version to a newer version of the process, so data should be more accurate starting about 16:00 UTC (4pm) today Jun 15.

BUT at any rate I will be working hard over the next few days to improve accuracy and debug the code

Sometimes it hard to keep up with the flow without switching to more expensive, multi-core server instances.

Thanks for your feedback, I will post updates here

Excellent news. Keep up the good work!  


Matt, I tried this before, but, I'll try again.
It looks to me that your chart does not include 50 sat/byte in the >= 50 sat/byte group. I think it is 51 sat/byte and over.
(comparing to bitcoinfees21)

Could you double check for me?
Thanks  

ps. don't think the bug is fixed!

UPDATE

There was a bug in the presentation of the stacked charts, where the cumulative values were used for each series instead of the correct data.

The bug has been fixed and all graphs are now correct.


Yes, but there is a much better transaction fee breakdown view coming up

How much is "enough" fees?
20 sat/byte is not the "recommended" fee, for swift transaction.

Simply put, all other transactions in the mempool with higher fees than 20 sat/byte will be included in a block first.
https://bitcoinfees.21.co/ are currently recommending a fee of 60 sat/byte.
Yesterday it went up to 80 sat/byte.
Yesterday, even transactions paying say 50 sat/byte were "delayed".

If you want to get into the next block, you must include a fee equal to, or more than the top 2000ish fees in the mempool.
The problem* yesterday was that people paying the recommended fee of 50 sat/byte were outbid by people paying the latest updated recommended fee of 60 sat/byte.
People paying 60 were then outbid by people paying 70, then 80.
So even though people paid "recommended" fees (of 150% more than you), those "recommended" fees were then superseded.

Unfortunately, matts chart here is too vague to be able to judge how much fee to pay.
(recommended fee on https://bitcoinfees.21.co/  is now 90 sat/byte, 450% higher than your "enough" fee)

Thanks, it's an early beta version and I'm working on a more real-time, better interface in the future. I also want to increase the expiry time from 8 hours to 72 hours to match the default mempoolexpiry.


Your transaction has enough fees: 4460 satoshi / 223 bytes = 20 satoshi / byte, but the queue is overloaded as you can see on the site

Nice website did not know before how to calculate the fees for each transaction. Normally I use XAPO and there you don't need to fill in any transaction amount. Will save this website could be really handy in the future.

Can you explain me if there was paid enough transaction fee for this transaction: https://blockchain.info/nl/tx/d62b6b403364bdf87faaa8a436baac510a35c6eed74fdfa1f891a083e5356348

Takes ages before this transaction processing still 0 confirmations.

It means exactly this:

Class 1: any transaction in the pool
Class 2: tx with fee >= 10 satoshi / byte
Class 3: tx with fee >= 50 satoshi / byte

(Class 1 - Class 2) = tx with fee less than 10 satoshi / byte
(Class 2 - Class 3) = tx with between 10 and 50 satoshi / byte

Currently there is an explosion both in size and number of transactions in the queue.

(reserved)

---

BitcoinQueue.com is a simple stacked chart visualization of the transaction queue waiting to be included in the next block(s) of the blockchain.



It's pretty straightforward and it shows interesting data that I was willing to share :-)

https://www.bitcoinqueue.com

Twitter: https://twitter.com/bitcoinqueue
Facebook: https://www.facebook.com/bitcoinqueue
Reddit: https://www.reddit.com/r/Bitcoin/comments/4o2udc/bitcoinqueuecom_real_time_bitcoin_blockchain/

If you find it interesting, make sure to leave feedback here.