Newbie (bitcoin node)

[Redhats]

Does the initial syncing mean that as time goes on it will take longer and longer to set up a node?

[un_rank]

It's actually getting faster.
The blockchain does not increase largely over long periods of time, in 2014 it was less than 200gb, ten years later, it still hasn't gone over 600gb. Download speed on the other hand is developing much faster, ten years ago 2-5 mbs was considered fast, today 500-1000 mbs is what's considered fast for most and some service providers can hit more than that.

- Jay -

[seoincorporation]

Does the initial syncing mean that as time goes on it will take longer and longer to set up a node?

The blockchain is growing every day, so, from that perspective the sync process will be longer in the future, i mean, isn't the same to sync a 200mb node than a 900mb node, but is important to mention how the sync process has become more efficient in the last core versions, if you try to sync a bitcoin node with the 1 version of bitcoin you will see how it take months to sync.

I don't doubt there will be new a better sync process in the future, it would be awesome to see a pruned where we can choose the starting block, that would save a lot of time and resources.

[Cricktor]

The blockchain does not increase largely over long periods of time, in 2014 it was less than 200gb, ten years later, it still hasn't gone over 600gb. Download speed on the other hand is developing much faster, ...

When was the last time you synced a full node and looked at current stats of a full node?

Code:

$ du -hd1   # as of today
603G	./blocks
12G	./chainstate
58G	./indexes
208M	./wallets
673G	.

The IBD gets more ressource intensive and for a faster sync you need more RAM as the UTXO set (see chainstate directory) has been bloated to around 12GB. You need a sufficiently large dbcache value so that file I/O isn't going to turn into a bottleneck when your free RAM for your node isn't large enough to hold the building UTXO set completely in RAM.

Your download speed isn't such an important factor with such a large UTXO set. Amount of RAM, dbcache size and I/O speed play a much larger role.

[pooya87]

Download speed on the other hand is developing much faster

That is a good point but keep in mind that what's being downloaded is data that needs to be processed. That requires computing power to verify everything inside each block, so your CPU is another important bottleneck.

[ranochigo]

It's actually getting faster.
The blockchain does not increase largely over long periods of time, in 2014 it was less than 200gb, ten years later, it still hasn't gone over 600gb. Download speed on the other hand is developing much faster, ten years ago 2-5 mbs was considered fast, today 500-1000 mbs is what's considered fast for most and some service providers can hit more than that.

- Jay -

Download or Upload speed has never been a factor since Bitcoin Core IBD is parallelized to different peers and it has never been the bottleneck of IBD ever since its introduction. Besides, your bandwidth benchmark would be a naturally inaccurate metric since it also depends on the upload speeds of your peers.

As mentioned previously, Bitcoin Core is heavily dependent on I/O, CPU and RAM. Ideal situation would be to just keep the chainstate in the RAM during IBD, and thereby negating the need to flush them frequently. Signature validation can possibly be a bottleneck on a slow CPU, fast I/O and sufficient ram since secp256k1 lib is quite optimized already. Else, your I/O and your ram are the likely bottlenecks.

[Redhats]

Is it possible to run the full node 24-7 on a local network server and then run a wallet on a another computer that would utilize the server as blockchain source ? How can i do that is there any i can learn more about ?
Thanks to anyone.

[STINKYBEE]

Is it possible to run the full node 24-7 on a local network server and then run a wallet on a another computer that would utilize the server as blockchain source ? How can i do that is there any i can learn more about ?
Thanks to anyone.

yes, as long as server has full Blockchain loaded (~600gb atm). it won't work the way you want to with purned mode. On another computer add to bitcoin.conf:
addnode=<server IP>:port, and you can use purned mode here just not the server.

[satscraper]

Is it possible to run the full node 24-7 on a local network server and then run a wallet on a another computer that would utilize the server as blockchain source ? How can i do that is there any i can learn more about ?
Thanks to anyone.

Sure you can do it.

For such setup you need both rpcbind (which is responsible for the connection on  network  layer in OSI model ) and  rpcallowip  (accountable for authorization in application layer ) entries in bitcoin.conf

Using Sparrow wallet's docs   as an example you  can configure such setup.

[NotATether]

Is it possible to run the full node 24-7 on a local network server and then run a wallet on a another computer that would utilize the server as blockchain source ? How can i do that is there any i can learn more about ?
Thanks to anyone.

Sure you can do it.

For such setup you need both rpcbind (which is responsible for the connection on  network  layer in OSI model ) and  rpcallowip  (accountable for authorization in application layer ) entries in bitcoin.conf

Obviously it is recommended that you only do this inside your local network. Do not attempt to make a wallet software connect to your node from the public internet, because who knows how many entities are listening in on the encrypted communication the wallet is sending to and from the node, via the many network cables connecting your computer to that server.

[ranochigo]

Obviously it is recommended that you only do this inside your local network. Do not attempt to make a wallet software connect to your node from the public internet, because who knows how many entities are listening in on the encrypted communication the wallet is sending to and from the node, via the many network cables connecting your computer to that server.

RPC is not encrypted, the support for SSL was removed quite a while ago. Even if you're connecting locally, I advise having a secure tunnel directly to the computer rather than connecting through RPC in cleartext.

[NotATether]

Obviously it is recommended that you only do this inside your local network. Do not attempt to make a wallet software connect to your node from the public internet, because who knows how many entities are listening in on the encrypted communication the wallet is sending to and from the node, via the many network cables connecting your computer to that server.

RPC is not encrypted, the support for SSL was removed quite a while ago. Even if you're connecting locally, I advise having a secure tunnel directly to the computer rather than connecting through RPC in cleartext.

Sorry, I meant to write unencrypted there. I was aware of that too. I also know of a way that you can create a TLS tunnel to a bitcoin node using stunnel that I used to use back in the day. It just needs a self-signed certificate.

I can share it with you if you want, but I will have to look for it on my server. It can work across different network interfaces too so not just localhost.