Topic: Installing a Full Node under Linux (Read 369 times)

If you want to contribute more to the network, run one unpruned full node, instead of many pruned. Pruned nodes don't advertise themselves as having any blocks, by default. They only relay unconfirmed transactions and the chain tip.

Alternatively, you can help by spreading the word. That's network contribution for sure. Encourage others to get involved into bitcoin. Encourage merchants to accept it. Vote for politicians that are supportive with the concept. Talk about bitcoin whenever you feel it can bring essence to a discussion. Educate your friends. Educate yourself.

This would certainly benefit everyone. Thank you for your effort.

I don't have write access to the docs but I'll find a section in the Wiki to insert this in, preferably one about Bitcoin Core (which I'm suspecting is as least 2-3 versions out of date?)

Of course, this is my goal --> to run minimum one full-node which is not pruned. Thank you

That's how the Bitcoin network works.. Who do you think you got the whole blockchain from? Other users with their own full nodes..
Even when initializing a pruned node, all the blocks need to be downloaded and the only way to get them is from other users who keep the 'full archive' (no pruning).

Good job, but again; if they're all pruned, they won't be uploading (helping the network) a lot at all..
Better run one full 'archival' node than 5 pruned, if you have the choice.

Understood. This information should IMHO be published officially on the documentation and wiki related to bitcoin-core and setup/installation. Thanks to all so far

I am running headless, so no QT on any of my nodes.

Yes, I understand the point of a full (unpruned) node. However I was curious if "uploading older blocks" has a certain reason and when this needs to happen, just for my understanding. BTW: Meanwhile I have installed and running five different nodes on various sites across the planet, I am trying to contribute as much as possible and affordable to me 

I just checked: it turns out the data directory isn't stored in that (which is inside the data directory). It's stored here:

hum..not quite sure any more, maybe yes maybe no ...
I don't. If I accidently posted some bash outputs with "root" showing than it was just because I was logged in with root at that moment I took the screen dump. But the daemon runs as user "bitcoin" which I created extra for this purpose. It's a restricted user account.

indeed. Thanks for pointing out. Related to the data structure l also found some interesting information here and here. Nevertheless, I would suggest to explicitly state that in the bitcoin-core documentation or wiki. A user would mistakenly assume that the prune value is what would be expected for the node setup related to the disk space required. However, we have just clarified that this is not the case. Unfortunately, I have not found any reference to this in any documentation so far. Only my recommendation to emphasize this.

Can you give examples why an average user should need to upload older blocks to other nodes, please? Is this something the user manually need to initiate and for what reasons ?

I guess you changed the data directory when you first started Bitcoin Core.


If you want it to fit in 6 GB, you'll have to prune to the minimum (550). But that doesn't leave much space for future growth.

You also can't upload older blocks to other nodes.

I thank you for the helpful responses so far. I have already read your HowTo, I have set up bitcoin-core very similar. At the moment I still have the following questions:

I had installed bitcoin-core on computer1 and computer2 in the same way. Computer1 is the slow armbian and computer2 is the fast computer with NVMe disk. Both nodes shut down before I got to work. I thought I had enough space on the fast computer2 so that I could download the whole blockchain, but unfortunately I was wrong and the space is not enough for the full blockchain. So I decided to run computer2 as a pruned node with the same settings as computer1. Both use the same configuration except that I could increase the dbcache on computer2. Computer2 was very quickly done with the IDB. Then I stopped bitcoin-core on computer2 again, so it was both nodes offline. Then I copied the folders "blocks" and "chainstate" from the fast computer2 to the slow armbian computer1. When I then started computer1 I got the error message that it could not find a block file and bitcoin-core was shut down again. This surprised me so I checked it out.

To my surprise I found out that computer2 used following folder structure for its block files:


While computer1 shows following structure:

(Question 1)
Simply said --> computer1 had no block files in its root folder ./blocks stored ! they are stored in another subfolder called blocks. Why did this happen, how is that possible, what caused this discrepancy ?

So after I copied the blocks/chainstate folder from computer2 to computer1, I had to manually create another sub-folder "blocks" on computer1 and move all *.dat files into this new subfolder. After that bitcoin-core started and found what it looked for and continued its work. However I am puzzled about this because as stated before both computers use the same bitcoin.conf, the configuration directives are exactly the same on both machines. Any clues ?

(Question 2)
My other question which unfortunately is still unanswered:

Let's say I have 6 GB of free space which I like to run my pruned bitcoin-core node on, so I configure prune=4096 on my node. I would expect that the node would not occupy more than this. But as you see it occupied more than twice the configured size. In that case the node would not be able to run because the file space would have been filled up already. So why do I have two folders with 4GB, total 9GB in my real life example ? I would have expected to see only 4GB file space claimed here.

(Question 3)
As far as I understood it correctly according to this wiki here ...
... my pruned node should have no further restrictions except that I cannot use -txindex, -coinstatsindex and -rescan, correct ? as long as I don't run/use the wallet function on that full-node I shouldn't miss anything important by those three switch functions, right?

Thus, I should not have any noticeable disadvantages with my pruned node, right?

(Question 4)
What about if I can't accept incoming connections on port 8333? Then my node only connects to a maximum of 10 outgoing nodes. Is that bad except that the whole network can't work correctly as peer-to-peer if everyone would operate it that way. But do I have any serious disadvantages otherwise? EDIT: I guess I've found an answer to this question. I conclude that it's not a real disadvantage when the node is running only as outbound. Of course it is not as much supportful for the network but I understand this. However, by the explained method using a TOR hidden service I could make it a supportful node again

In general, I would always refer to the (very prominently placed) link on top of this forum, or go directly to GitHub with its easy to memorize URL: https://github.com/bitcoin/bitcoin

Exactly; don't bother with lnd on a low-power system, get Core Lightning right away.

You may also be able to use large parts of my FutureBit Apollo BTC full node install guide. It is just an Orange Pi 4.
https://bitcointalksearch.org/topic/guide-futurebit-apollo-btc-custom-linux-install-node-5401747

One key difference is that you're running 32-bit ARM instead of 64-bit ARM, and the path to your external drive will be different. You may also be running a different OS with different package manager / package names.
But in general, you can follow the steps as outlined there.

Very good point! The initial block download will be an issue. It is possible to do the IBD on a powerful desktop PC, gracefully shut down Bitcoin Core and then remove the HDD and put it into the SBC node.

See my experience below. With 4GB of RAM and HDD, it took almost a week for the first 50% (and it's not linear growth), as soon as I added 4GB of RAM, it finished in around a day. It would have taken multiple more weeks to finish with just the 4GB, unfortunately.

You don't normally need to run a full node for mining. You just choose a solo (or regular) pool like https://kano.is/ and use Stratum protocol.

Chainstate is the one I mentioned earlier: it gets a lot of write access during syncing:
I think that's enough, but I also think files like mempool.dat and peers.dat won't hurt to add. So I'd just copy everything except for your wallet.

Back to your original question:
Why did you switch to a pruned node? I've tested it, and a pruned node can indeed upload more than it downloads, but it's not much in total. To compare: my full node uploads about 40 GB per day.

Yes, the chainstate and the blocks directories will transfer from one node to another.  However, you'll still need to synchronize the new install on computer2, and if you're using a HDD, that will be slow anyway.  Once upon a time I tried to install core on an RPi with a HDD plugged into one of the USB ports.  IIRC it took over three weeks to synchronize, and that was with another local node specified by addnode, so download speeds weren't an issue.  Also, if I recall the blockchain was around 360GB at the time, quite a bit less than it is right now.

Another action that can lead impatience with a slow HDD is importing addresses.  Read speeds on HDDs are faster than wright speeds, so it's less of an issue, but it's still noticeably slower than a node running on a SSD.

Let's say I have computer1 which is low-spec and computer2 which has better hardware and thus is much faster. I have installed bitcoin-core 23.0 on both of them and started bitcoind, the setting on both computers is to run a pruned node with 4 GiB. Computer2 was very fast as I utilized a lot of db cache because of the high available RAM on that computer2. It finished already and is up-to-date. Side note: I wonder why I have two big directories under ./bitcoin/

5.0 G   chainstate
4.0 G   blocks

I'd have expect to see only 4GB of data because I configured prune=4096 in my bitcoin.conf file.

Now I stopped bitcoind on both computers and I would like to copy the necessary files from computer2 to computer1 to save time and bandwidth for computer1. My goal is to bring up both nodes and run them simultaneously.

How should I do that, which folders are necessary to copy over to computer1 ? I assume it's not good to copy the whole .bitcoin directory over to the slower computer1 cause I think computer2 might use some sort of fixed data that are relevant only to computer2 (maybe some hardware or cookie IDs, or whatever I am not aware of...) Will it be enough to copy the folders chainstate and blocks, or maybe only blocks folder is enough ?

please enligthen me   thank you

EDIT: I found some helpful information here and if understood correctly I was on the right path. I guess I will try to copy only those two mentioned folder chainstate and blocks and keep the rest of the folders/files content on each installation to their own.

However, anyone please give me a reply to the above question about the high folder sizes ?

1GHz and 2GB RAM with 1TB SATA hard disk is too slow in middle of step, 50% downloading block will have trouble slow sync and stuck. I ever used core 2.5 GHz and 4GB RAM with 1TB SATA hard disk, the trouble begin on middle block. I suggest to you upgrade all spec than wasted

Alright, I don't have any problem waiting for weeks until the sync is finished so I'll go that way nevertheless I'd like to know: in case of running a pruned node (let's say with pruned=10000) do I have any restrictions when using this node for mining ?

Correct. One block per 10 minutes isn't very demanding, and (as far as I know) uploading blocks requires mostly linear reading from disk.

Do I interpret correctly from this that the disk performance and thus your suggestion is based on the fact that it is only decisive for the IBD? As soon as the IBD is completed, the hard disk performance plays a rather subordinate role?

It's slow
When syncing, Bitcoin Core verifies all blocks. I've tested it in the past, and putting chainstate on SSD gives a significant performance improvement. Using 4 GB as dbcache helps a lot too, but you'll need more RAM for that.

It's not crucial, but makes a big difference.

If at all possible, plug in the SATA disk and run chainstate from the NVMe. Add 4096 dbcache and syncing should be done in half a day. Then move everything to your other system.