How long does it take for a bitcoin node to find the latest block?

[Zyger]

I'm just wondering how long it would take an average full bitcoin node to find the latest block compared to the main blockchain explorers.

This is because I'm planning on using the bitcoin node to get information about new blocks, and it needs to be relatively fast.

I'd test it myself, but my internet is slow, and I don't want to have to buy a VPS until I'm sure that I want to do it this way.

Thanks.

[DannyHamilton]

I'm just wondering how long it would take an average full bitcoin node to find the latest block compared to the main blockchain explorers.

This is because I'm planning on using the bitcoin node to get information about new blocks, and it needs to be relatively fast.

I'd test it myself, but my internet is slow, and I don't want to have to buy a VPS until I'm sure that I want to do it this way.

Thanks.

That depends on how well connected it is.

If it has a direct connection to the mining pool that solves the block, then your full node will hear about the block as soon as (or sooner than) any other blockchain explorer website.

If it does not have a direct connection to the mining pool that solves the block, then it could take as much as a few seconds (depending on just how many connections the block has to pass through before it gets to you and how fast those connections relay the block).

Unless you make a specific effort to configure your full bitcoin node to have a direct connection to all (or most) of the major mining pools, I'd expect your average time to be somewhere between those extremes.  Sometimes you'll get it a fraction of a second after the blockchain explorer site, and sometimes you'll get it at the same time (or maybe a fraction of a second before if they aren't well connected at that moment.

[ranochigo]

If you have a poor latency to your peers, then you'll probably experience significant delays. Block headers are fairly small to relay and can be relayed first before the block itself so bandwidth is no issue there if you only want to be notified of the latest block. As mentioned, the timing would vary depending on how many hops a specific block take before it reaches the target node and it would vary from time to time.

You also have to factor in the latency between the block explorer if you want to get your data from there. Here's a few blocks that I have compiled between two nodes that are fairly far apart, geographically. Interestingly, the difference is only 2 seconds but there's definitely insufficient sample size. Unfortunately, I'm unable to compare this to the Blockchair as they seem to be using Median time which doesn't reflect the actual time received.

Code:

Home Node: 2021-03-13T04:42:27Z UpdateTip: new best=0000000000000000000086661c2e8852a683d62aef5712d29e91918041c1f844 height=674386 version=0x20400000 log2_work=92.731396 tx=624319389 date='2021-03-13T04:42:17Z' progress=1.000000 cache=311.2MiB(2310354txo)
Dedicated Node: 2021-03-13T04:42:25Z UpdateTip: new best=0000000000000000000086661c2e8852a683d62aef5712d29e91918041c1f844 height=674386 version=0x20400000 log2_work=92.731396 tx=624319389 date='2021-03-13T04:42:17Z' progress=1.000000 cache=200.4MiB(116>

Home node: 2021-03-13T04:41:52Z UpdateTip: new best=000000000000000000091afc491f67dc650c37b33bdbacb2a5dd284d01090f00 height=674385 version=0x20000000 log2_work=92.731380 tx=624319194 date='2021-03-13T04:41:56Z' progress=1.000000 cache=310.4MiB(2304030txo)
Dedicated Node: 2021-03-13T04:41:50Z UpdateTip: new best=000000000000000000091afc491f67dc650c37b33bdbacb2a5dd284d01090f00 height=674385 version=0x20000000 log2_work=92.731380 tx=624319194 date='2021-03-13T04:41:56Z' progress=1.000000 cache=200.4MiB(116>

Home node: 2021-03-13T04:39:49Z UpdateTip: new best=00000000000000000001a00e6957773a5191493353f553249c0d97d8b2ffbadd height=674384 version=0x20000000 log2_work=92.731364 tx=624318828 date='2021-03-13T04:39:27Z' progress=1.000000 cache=309.6MiB(2297496txo)
Dedicated Node: 2021-03-13T04:39:47Z UpdateTip: new best=00000000000000000001a00e6957773a5191493353f553249c0d97d8b2ffbadd height=674384 version=0x20000000 log2_work=92.731364 tx=624318828 date='2021-03-13T04:39:27Z' progress=1.000000 cache=200.3MiB(116>

[Zyger]

That depends on how well connected it is.

If it has a direct connection to the mining pool that solves the block, then your full node will hear about the block as soon as (or sooner than) any other blockchain explorer website.

If it does not have a direct connection to the mining pool that solves the block, then it could take as much as a few seconds (depending on just how many connections the block has to pass through before it gets to you and how fast those connections relay the block).

Unless you make a specific effort to configure your full bitcoin node to have a direct connection to all (or most) of the major mining pools, I'd expect your average time to be somewhere between those extremes.  Sometimes you'll get it a fraction of a second after the blockchain explorer site, and sometimes you'll get it at the same time (or maybe a fraction of a second before if they aren't well connected at that moment.

Oh okay, if it's only a few seconds at the most then that's perfect. I was thinking that it may end up being like a minute.

If you have a poor latency to your peers, then you'll probably experience significant delays. Block headers are fairly small to relay and can be relayed first before the block itself so bandwidth is no issue there if you only want to be notified of the latest block. As mentioned, the timing would vary depending on how many hops a specific block take before it reaches the target node and it would vary from time to time.

You also have to factor in the latency between the block explorer if you want to get your data from there. Here's a few blocks that I have compiled between two nodes that are fairly far apart, geographically. Interestingly, the difference is only 2 seconds but there's definitely insufficient sample size. Unfortunately, I'm unable to compare this to the Blockchair as they seem to be using Median time which doesn't reflect the actual time received.

Code:

Home Node: 2021-03-13T04:42:27Z UpdateTip: new best=0000000000000000000086661c2e8852a683d62aef5712d29e91918041c1f844 height=674386 version=0x20400000 log2_work=92.731396 tx=624319389 date='2021-03-13T04:42:17Z' progress=1.000000 cache=311.2MiB(2310354txo)
Dedicated Node: 2021-03-13T04:42:25Z UpdateTip: new best=0000000000000000000086661c2e8852a683d62aef5712d29e91918041c1f844 height=674386 version=0x20400000 log2_work=92.731396 tx=624319389 date='2021-03-13T04:42:17Z' progress=1.000000 cache=200.4MiB(116>

Home node: 2021-03-13T04:41:52Z UpdateTip: new best=000000000000000000091afc491f67dc650c37b33bdbacb2a5dd284d01090f00 height=674385 version=0x20000000 log2_work=92.731380 tx=624319194 date='2021-03-13T04:41:56Z' progress=1.000000 cache=310.4MiB(2304030txo)
Dedicated Node: 2021-03-13T04:41:50Z UpdateTip: new best=000000000000000000091afc491f67dc650c37b33bdbacb2a5dd284d01090f00 height=674385 version=0x20000000 log2_work=92.731380 tx=624319194 date='2021-03-13T04:41:56Z' progress=1.000000 cache=200.4MiB(116>

Home node: 2021-03-13T04:39:49Z UpdateTip: new best=00000000000000000001a00e6957773a5191493353f553249c0d97d8b2ffbadd height=674384 version=0x20000000 log2_work=92.731364 tx=624318828 date='2021-03-13T04:39:27Z' progress=1.000000 cache=309.6MiB(2297496txo)
Dedicated Node: 2021-03-13T04:39:47Z UpdateTip: new best=00000000000000000001a00e6957773a5191493353f553249c0d97d8b2ffbadd height=674384 version=0x20000000 log2_work=92.731364 tx=624318828 date='2021-03-13T04:39:27Z' progress=1.000000 cache=200.3MiB(116>

I plan on using an OVH VPS to host the bitcoin node, so hopefully the latency should be good enough.

The block explorer doesn't matter too much for me, since I'll only be using it to get general information about unconfirmed transactions, such as the time they was first seen and the fee that they're using.

Thanks for the help both of you

[DannyHamilton]

Oh okay, if it's only a few seconds at the most then that's perfect. I was thinking that it may end up being like a minute.

A minute isn't COMPLETELY outside the realm of possibility, but it would be pretty unusual.  You'd have to be isolated from the larger network, and have one or more peers between your node and the full network that were extremely slow in relaying (perhaps intentionally?).

The block explorer doesn't matter too much for me, since I'll only be using it to get general information about unconfirmed transactions, such as the time they was first seen and the fee that they're using.

If you are already running your own full node, and you are already writing code to recognize new blocks, why trust a block explorer for "time first seen" or "transaction fee"?  Why not just capture for yourself when your node first sees the transaction, as well as what the fee is?

[Zyger]

Oh okay, if it's only a few seconds at the most then that's perfect. I was thinking that it may end up being like a minute.

A minute isn't COMPLETELY outside the realm of possibility, but it would be pretty unusual.  You'd have to be isolated from the larger network, and have one or more peers between your node and the full network that were extremely slow in relaying (perhaps intentionally?).

The block explorer doesn't matter too much for me, since I'll only be using it to get general information about unconfirmed transactions, such as the time they was first seen and the fee that they're using.

If you are already running your own full node, and you are already writing code to recognize new blocks, why trust a block explorer for "time first seen" or "transaction fee"?  Why not just capture for yourself when your node first sees the transaction, as well as what the fee is?

I read somewhere that it can be inaccurate, so I thought it would be best to base the "time first seen" off of a block explorer's data since I assume they'd see it faster.

I'm only using it to get the transaction fee since the request I'd be using to get the time shows that as well, saving me having to do a few more rpc requests.

I'm making a bot that pings users when their transactions confirm with details about it, so that's why I'm trying to make it accurate.

[ranochigo]

I read somewhere that it can be inaccurate, so I thought it would be best to base the "time first seen" off of a block explorer's data since I assume they'd see it faster.

No guarantees that they are perfectly accurate as well. There are plenty of potential (small) delays from them getting the block, validating it, updating the site, their APIs, etc. Its much better to just host your own node yourself and use the RPC. After all, you wouldn't be rate limited by those APIs and there would also be times where you're faster than the block explorer, they're just another node like you.

[Zyger]

I read somewhere that it can be inaccurate, so I thought it would be best to base the "time first seen" off of a block explorer's data since I assume they'd see it faster.

No guarantees that they are perfectly accurate as well. There are plenty of potential (small) delays from them getting the block, validating it, updating the site, their APIs, etc. Its much better to just host your own node yourself and use the RPC. After all, you wouldn't be rate limited by those APIs and there would also be times where you're faster than the block explorer, they're just another node like you.

Ahh okay, I'll probably use my node for that then, thanks.

If you have a poor latency to your peers, then you'll probably experience significant delays. Block headers are fairly small to relay and can be relayed first before the block itself so bandwidth is no issue there if you only want to be notified of the latest block.

On reality, if your node is fully synced, it'll use block compact where a node don't need to send whole blocks since most transaction already on your mempool.

To OP, you might want to read this page (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) which contain few information about latency.

Thanks, I'll check it out.

[ranochigo]

The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block

I assume you got the information from the research papers?

It was pretty outdated and that is probably not the case anymore. You no longer have to send the whole block over to the peers with compact block, you're at most sending the primary data concerning the block and only send the transactions that are requested by your peers. While there will still be some delay, you can't measure the mean delay and take it as it is. Some nodes are bound to be more well connected than others and skew the results.