Newbie (bitcoin node)

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

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 -

Quote from: Redhats on May 06, 2024, 01:59:36 PM

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.

Quote from: un_rank on May 06, 2024, 05:33:42 PM

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.

Quote from: un_rank on May 06, 2024, 05:33:42 PM

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.

Quote from: un_rank on May 06, 2024, 05:33:42 PM

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.

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.

Quote from: Redhats on May 07, 2024, 04:27:43 PM

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.

Quote from: https://sparrowwallet.com/docs/connect-node.html

Quote from: satscraper on May 07, 2024, 05:23:40 PM

Quote from: Redhats on May 07, 2024, 04:27:43 PM

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.

Quote from: NotATether on May 09, 2024, 06:40:49 AM

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.

Quote from: ranochigo on May 09, 2024, 07:11:43 AM

Quote from: NotATether on May 09, 2024, 06:40:49 AM

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.