Author

Topic: How to achieve fastest node -- 2 minutes delay on block reception (Read 226 times)

sr. member
Activity: 490
Merit: 389
Do not trust the government
To clarify/correct a comment made above ...

The block time stamp is NOT the time the block was found.
It is something else.

Rather than going into details about what it IS, it is easiest to point out that it is NOT set to be the block find time.

Well now you are just teasing us...
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
To clarify/correct a comment made above ...

The block time stamp is NOT the time the block was found.
It is something else.

Rather than going into details about what it IS, it is easiest to point out that it is NOT set to be the block find time.
newbie
Activity: 10
Merit: 2
Ok this is embarrassing, the default windows NTP server was enabed but not working so my PC was indeed more than a minute ahead. This already fixes a large part of the delta. Thanks for all other responses, I can assume all will be a factor for the remaining 40 seconds delay.

I'm still trying to achieve the least as possible, so any other hints or tuning methodes are welcome.

@ETFbitcoin Are the node addresses of miners public? Where to find them? And do they accept any incoming connection as I can imagine a lot of people will want to connect to them for various reasons.
staff
Activity: 3458
Merit: 6793
Just writing some code
The timestamp on the block is not guaranteed to to be the correct time that the block was actually found. Miners can manipulate the block time quite a bit, so it doesn't reliably tell you when a block was found.

Propagation can also take a long time depending on how far away from the miners you are.

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.
FIBRE is not really what you are looking for. You already are using compact blocks as that is in Bitcoin Core. Compact blocks is unrelated to transaction relay times.
sr. member
Activity: 490
Merit: 389
Do not trust the government
Well, make sure first that your system clock is showing the right time.
Other than that, check if your CPU is strong enough to verify and index blocks fast enough.
SSD drive might help as well.
newbie
Activity: 10
Merit: 2
Hi,

I have a Bitcoin core node running (0.16.1) which has 16 outgoing connections (to other fast/stable nodes according to Bitnodes) + approx 8 incoming connections. Full blockchain is synced and all txns are indexed.

Whenever a new block comes in, I can see that the time my node processes it is 2 minutes later than the timestamp on the block. What is the reason of this delay? I can't imagine the propagation will always take this long so is there anything else that might be affecting this?

What are normal delays?

For academic purposes I would like to achieve the least delay possible. What could be options to achieve this? I've read that having more peers would not help but can have an opposite effect?

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.

kr
Jump to: