Why Bitcoin node outbound is 10 and inbound is more.

I set up a node and I noticed the outbound connection start from zero to 10 and it retained that number of peer nodes continuously. I noticed that the more number of peers you have, the faster the sync becomes. So my question is if more outbound connection with other nodes makes sync faster with stable internet, why not increase the outbound so it can download blocks from other peers even faster instead of the 10.

This number is the same on Bitcoin core and Bitcoin knot.

Quote from: PVequalNRT on July 06, 2026, 09:49:42 AM

-snip- I noticed that the more number of peers you have, the faster the sync becomes.

It doesn't always go that way.
The default 10 (+1) should be enough if at least one or two of them is serving blocks fast enough.

And it's not just the download speed that dictates how fast your node sync,
It's also the verifications and Disk IO which in most hardware, can't keep up with how fast you can download blocks.

Quote from: PVequalNRT

So my question is if more outbound connection with other nodes makes sync faster with stable internet, why not increase the outbound so it can download blocks from other peers even faster instead of the 10.

Based from my point above, the actual solution is to drop outbound peers that are stalling your IBD which is already implemented years ago.

If it's getting slow, there may be a bottleneck somewhere that doesn't involve your download speed (check your hardware, specially the drive)

Quote from: PVequalNRT on July 06, 2026, 09:49:42 AM

It's intentional by design. There are far less total nodes and total nodes that accept incoming connection. https://bitref.com/nodes/ shows there are about 77498 public nodes (i don't know if it means all nodes or only non-reachable node), but it also shows there are only about 18107 reachable nodes. If the limit is much higher than 10 or there's no limit, it would put more burden reachable nodes.

There are some options to make IBD faster, but it doesn't guarantee smooth and fast sailing.

Use SSD storage where your chainstate is located, blocks directory isn't too bad on spinning rust, if you don't have the space on a SSD. You should avoid having chainstate directory on a harddisk, unless you have a lot of RAM (enough to safely assign maybe dbcache=14000 and to keep your OS and other apps still happy and away from swap space; likely a 32GiB RAM scenario, 24GiB might be fine, too).

Increase dbcache as much as possible, but use reasonable values and enough left for your OS and other activities on your device. You don't want to trigger high memory pressure and worst, too much swapping.

During IBD setting blocksonly=1 is probably a good idea, removing the burden for your node to handle and verify transactions and maintaining a mempool when your only goal is to get to the chain tip as fast as possible.

When current chainstate is in the ballpark of ~11GiB and the UTXO set can't be held in RAM most of the time during IBD, a lot of I/O to storage is the consequence which doesn't speed it up apparently (low RAM and only a harddisk can or rather will be quite a crawl).

Just be patient and don't expect IBD miracles.

Quote from: Cricktor on July 07, 2026, 10:10:46 PM

When current chainstate is in the ballpark of ~11GiB and the UTXO set can't be held in RAM most of the time during IBD, a lot of I/O to storage is the consequence which doesn't speed it up apparently (low RAM and only a harddisk can or rather will be quite a crawl).

According to https://statoshi.info/d/000000009/unspent-transaction-output-set, the peak was about 12.8GB. But rest of your recommendation still apply whether it's about 11GB or 12.8GB.

Quote from: PVequalNRT on July 06, 2026, 09:49:42 AM

~snip

Personally i don't really think more outbound peers will automatically make syncing faster. If i am right bitcoin Core and Knots already download blocks in parallel from the fastest peers and i think after around 10 outbound connections the gains should actually be minimal while stuffs like CPU memory and network overhead will then increase.

So basically the default settings already have is actually more of a balance between things like performance and efficiency. adding more peers will only put more load on your computer instead and it is not like it will make a big difference in your download speed.

Quote from: ABCbits on Today at 07:56:03 AM

...

Oh well, you're right, I didn't think much about it that chainstate size might've been worse in the past than right now when I did a 'du -h ~/.bitcoin' to have a brief look at how large it is for my full-node.

Thanks for the reminder to try to look at the bigger picture.

My Core node(s) also have set the option

Code:

maxuploadtarget=0

to not limit how much other nodes might want to pull from mine. So far I didn't experience excessive IBD pulls from other nodes, all is within well behaved bounds. My nodes run via Tor and that might impose some bandwidth limits on its own.

Monthly traffic isn't any worrying and my ISP never bothered me.