Why are we crippling the initial sync?

[thefreshprinceofbell]

There are 10,000 full nodes many of them on fiber connection ready and willing to share the full Bitcoin blockchain.

But the core client only connects to 8-9 outbound nodes by default with no way to change this, other than manually adding clients.

source: https://bitcoin.stackexchange.com/a/8140

I'm running on 4 year old hardware and only utilizing 3% CPU and 25% memory with the only constraint being downloading the blocks. Currently my sync time is pegged at 4 weeks but when I manually add clients it drops to 40 hours.

There are not enough new nodes coming online for Pieter Wuille's explanation to make sense. There is no reason someone should have to download the Blockchain via Bittorrent to speed syncing because the Core client is purposely crippling the network.

We need to fix this if we want new users to run full nodes. More importantly lightning network depends on people running full nodes. Most people are going to lose interest when you tell them it will take 4 weeks to sync.

[1714838689]

1714838689

[1714838689]

1714838689

[1714838689]

1714838689

[achow101]

I'm running on 4 year old hardware and only utilizing 3% CPU and 25% memory with the only constraint being downloading the blocks.

What about disk I/O? Disk I/O is usually a major bottleneck because Bitcoin Core constantly reads and writes from storage. The updating of the UTXO set during validation causes a lot of disk I/O and it can often end up being the bottleneck.

If you increase the dbcache parameter, more of the database can be held in memory which improves the sync time.

Currently my sync time is pegged at 4 weeks but when I manually add clients it drops to 40 hours.

Did you measure that or is that what the estimate says?

There are not enough new nodes coming online for Pieter Wuille's explanation to make sense.

How do you know?

There is no reason someone should have to download the Blockchain via Bittorrent to speed syncing

Indeed, and that hasn't been the case for several years. The bootstrap.dat that you could download via torrent previously is no longer maintained and, at the time it was phased out, slower than allowing Bitcoin Core to sync by itself.

[thefreshprinceofbell]

What about disk I/O? Disk I/O is usually a major bottleneck because Bitcoin Core constantly reads and writes from storage. The updating of the UTXO set during validation causes a lot of disk I/O and it can often end up being the bottleneck.

If you increase the dbcache parameter, more of the database can be held in memory which improves the sync time.

On a SSD, but will increase.

How do you know?

https://bitnodes.io/dashboard/?days=730

Did you measure that or is that what the estimate says?

Based on the estimate and how much I've managed to sync over the last three days.

More importantly when I added a bunch of Nodes manually the estimate dropped to 40 hours. and speed of sync dropped dramatically.

[ranochigo]

https://bitnodes.io/dashboard/?days=730

Those are the nodes which allows incoming connection. It's methodology gives an inaccurate sampling of the actual node count as it doesn't take into account the nodes that doesn't allow incoming connection.

Based on the estimate and how much I've managed to sync over the last three days.

More importantly when I added a bunch of Nodes manually the estimate dropped to 40 hours. and speed of sync dropped dramatically.

Adding nodes may not always help. Some nodes are crawlers which will not help in your synchronization and would infact slow it down. The synchronization estimate will fluctuate quite wildly, when it hits a patch closer to the present day, the synchronization would slow down a lot as the more recent blocks contains much more transactions to be validated. Increasing the dbcache will help quite a lot.

Depending on your SSD model, some QLC SSDs will slow down significantly after the cache gets filled.

[thefreshprinceofbell]

Those are the nodes which allows incoming connection. It's methodology gives an inaccurate sampling of the actual node count as it doesn't take into account the nodes that doesn't allow incoming connection.

I knew I would get a comment like this.

Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret?  Or can we go with the simpler explanation of not many people are bothering to spin up a node and we shouldn't be making it harder to do so because at some point it may or may not be a problem.

when it hits a patch closer to the present day, the synchronization would slow down a lot as the more recent blocks contains much more transactions to be validated. Increasing the dbcache will help quite a lot.

Currently at June 2016 and progressing at 0.13% and hour.

Depending on your SSD model, some QLC SSDs will slow down significantly after the cache gets filled.

Samsung SN550, if a QLC drive causes it to take 4 weeks to sync something is really broken with the network.  But like I said when I manually added a bunch of nodes that had either TELUS or Google Fiber as their ISPs my sync time dropped to 40 hours.  Slowly as they disconnect and I go back to the 8-9 nodes my sync time goes back to 3 weeks.

[ranochigo]

I knew I would get a comment like this.

Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret?  Or can we go with the simpler explanation of not many people are bothering to spin up a node and we shouldn't be making it harder to do so because at some point it may or may not be a problem.

Well, yes. If the service only records nodes that it can establish a connection to, then it wouldn't reflect those which aren't allowing it. There really isn't a reliable way to get every single node in the world.

There isn't anyone trying to make the synchronization any harder than it is. Loads of optimizations have been made but older computers will still suffer due to their hardware. IBD will be the longest process for most so it really isn't that big of a concern as you're only doing it once.

Samsung SN550, if a QLC drive causes it to take 4 weeks to sync something is really broken with the network.  But like I said when I manually added a bunch of nodes that had either TELUS or Google Fiber as their ISPs my sync time dropped to 40 hours.  Slowly as they disconnect and I go back to the 8-9 nodes my sync time goes back to 3 weeks.

Definitely shouldn't take 4 weeks, especially with NVMe if you're talking about WD SN550. My synchronization took a day with my HDD and 6 hours on my SATA SSD but they had 6GB of dbcache. Is your ISP throttling your connection by any chance?

[thefreshprinceofbell]

Definitely shouldn't take 4 weeks, especially with NVMe if you're talking about WD SN550. My synchronization took a day with my HDD and 6 hours on my SATA SSD but they had 6GB of dbcache. Is your ISP throttling your connection by any chance?

Sorry you are correct WD SN550 not Samsung.  I have a gigabit Fiber to the home connection and my sync speed jumps like crazy when I manually add nodes so I don't think they are throttling.

[achow101]

I knew I would get a comment like this.

Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret?  Or can we go with the simpler explanation of not many people are bothering to spin up a node and we shouldn't be making it harder to do so because at some point it may or may not be a problem.

Yes because that's the default behavior.  In order to accept incoming connections, you need to configure your router to allow incoming connections to port 8333. Most users aren't going to or don't know how to do that. Not to mention the fact that there will be people running Bitcoin Core on computers where they can't control the router to allow incoming connections. Additionally many people run Bitcoin Core on laptops, and given their portable nature, aren't usually set up to accept incoming connections.

Samsung SN550, if a QLC drive causes it to take 4 weeks to sync something is really broken with the network.  But like I said when I manually added a bunch of nodes that had either TELUS or Google Fiber as their ISPs my sync time dropped to 40 hours.  Slowly as they disconnect and I go back to the 8-9 nodes my sync time goes back to 3 weeks.

Sorry you are correct WD SN550 not Samsung.  I have a gigabit Fiber to the home connection and my sync speed jumps like crazy when I manually add nodes so I don't think they are throttling.

That does sound like a network bottleneck for you, however just increasing the number of connections won't necessarily solve the problem. You have specifically connected to high speeds nodes, there is no guarantee that just an increased connection count would have your node connect to those.

How are you connecting to those nodes? It should be possible to make the connection type one that Bitcoin Core connects to automatically if the connection drops.

[pooya87]

Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret?

This is not "in secret" and the number of nodes not accepting incoming connections can be measured to some extent. You just have to accept incoming connections with a decent internet speed and advertise your IP address (ie. send your addr message). Then you'll see all those nodes show up at your doorstep. Do this long enough with a reliable connection on the same IP and you can count the unique IP addresses.

[aliashraf]

There are 10,000 full nodes many of them on fiber connection ready and willing to share the full Bitcoin blockchain.

But the core client only connects to 8-9 outbound nodes by default with no way to change this, other than manually adding clients.

source: https://bitcoin.stackexchange.com/a/8140

I'm running on 4 year old hardware and only utilizing 3% CPU and 25% memory with the only constraint being downloading the blocks. Currently my sync time is pegged at 4 weeks but when I manually add clients it drops to 40 hours.

There are not enough new nodes coming online for Pieter Wuille's explanation to make sense. There is no reason someone should have to download the Blockchain via Bittorrent to speed syncing because the Core client is purposely crippling the network.

We need to fix this if we want new users to run full nodes. More importantly lightning network depends on people running full nodes. Most people are going to lose interest when you tell them it will take 4 weeks to sync.

Great title for a topic and disappointing followup, both for you as the op and others who've contributed untill now.

Initial sync process for bitcoin is crippled not by what you think, a default number of 8 outbound connections which you can override it anyway! Who cares about defaults, and how does this specific number relate to days of bootstrapping lag for bitcoin in the wake of 5G internet?

Bitcoin initialization process is crippled not because of stupid defaults, come on, it is obvious, it is due to the pathetic, baseless, infamous slogans about the holly verification thing that are circulating around in the community, and by verification they mean the current naive approach of bitcoin despite lots of smart ideas and proposals out there.

[thefreshprinceofbell]

Care to share how you can change this on the default client without changing the source and recompiling?  As I understand you can only change the default inbound peers, but I would love to be proven wrong.

[aliashraf]

Care to share how you can change this on the default client without changing the source and recompiling?  As I understand you can only change the default inbound peers, but I would love to be proven wrong.

You have two options:
1- Add some nodes manually using -addnode argument.
It is the easiest and most effective option because you need to spot efficient nodes on the backbone for testing your theory.

2- Go to cpp.net and change MAX_OUTBOUND_CONNECTIONS then make bitcoind.

[thefreshprinceofbell]

So not much of default setting problem but a systemic problem with the client.  Sure you could fix any software issue by recompiling it but how about we ask why are we crippling the network in the first place?

[aliashraf]

As of the crippling thing, you are accusing the wrong suspect, as I've reminded above, it has nothing to do with the number of outgoing connections, I insist.

As of your suspect per se, the upper bound devised in Core client for the number of outgoing connections, I think it is a good trade-off decided wisely by the devs because nodes that do not accept incoming connections typically tend to be less active and "silent". Why should such nodes make dozens of connections to other nodes, saturating their resources? What could be considered as the legitimate incentive behind such a paradoxical behavior?
 
You want more connections? Let people connect to your node as well, both incoming and outgoing connections are full-duplex, functioning indifferently after all, and good news is that you can configure the maximum number of incoming connections trivially and deliberately.