Topic: Pros and Cons of Bitcoin Node types (Full node and Prune node) (Read 1247 times)

Spend more time in the field working on cheap systems and you will change your mind.
In the general position that a real name brand SSD will always be faster then a real name brand HDD you are 100% correct.

But, and this is probably more for the build a node for under $50 thread, since there is where people are trying to do something on the cheap, you would be amazed the number of off brand SSDs out there that are selling for 1/2 or less of what a real name one is selling for. They have NO CACHE, an outdated controller chip and the storage is a couple of generations out of date (and may have been used and repurposed from other drives).

But its cheap, so people but it, and then wonder why the SSD they got did not improve system performance.

I have a pile of almost new 2TB HDD I just pulled out of storage for recycling, BUT they are all dated 2010. Back then they were the fastest drives you could get in that size. Today the low end consumer ones are faster. Do you want an SSD with a controller from 7 years ago? They are out there being sold now for cheap.

Much like we have been saying about the investment scams (FTX and such) in terms of money, hardware is the same way. If it's too good to be true it probably is.

If you don't deal with a lot of end users trying to save money you may not see this, but I do on a somewhat regular basis. Even in higher end environments that should know better.

-Dave

I think you're missing the point Saying an SSD is faster than HDD is like saying a car is faster than a bicycle. There are exceptions, but in general, it's correct. Saying you need HDD and not SSD is not correct.
I had no problems doing IBD on a server with HDD and enough RAM, but I once tested and noticed a significant different in startup time between having chainstate on HDD vs having it on SSD. Hence my recommendation to, if at all possible, at least put chainstate on SSD. The rest doesn't matter much (unless you frequently load very old wallets).

The issue is, at least in IMO SSD vs HDD is **WAY** too generic.
It's like saying car. Did you get the cheapest thing that anybody puts out, a Honda Accord or a Mercedes S580?

There are SSDs out there that are utter crap and quality performance HDD that cost more then SSD and are faster.

I have been saying in other posts about blockchain storage that I am sitting on a pile of fairly low hour, name brand HDD that I give away to people who need them since they are just not worth selling. I since they pass crystal disk info with no problems I would have no issues having someone store stuff on the,

OTOH on some sites like Amazon and NewEgg you see SSD from brands that I have never heard of that are 1/3 the price of a name brand drive.
Raise your hand if you want to help people diagnose issues with their node if they are running one of those.
Makes you wonder how much time this forum has spent helping people with an SSD that was made so poorly with such low grade chips that it's amazing it works never-mind if it can keep up with IBD

-Dave

For the record: there's no reason not to use SSD (unless your budget doesn't allow it). Since I'm still low on SSD-storage, I have chainstate on SSD and the rest of the data on HDD. That's the best compromise for performance.

Time flies so fast and after about 3 years, Bitcoin blockchain size increases from less than 300 GB to 440.43 GB at 29 November 2022 according to ycharts.com

If you want to run a full node, a hard disk (should be HDD, not SSD) with free space about 500 GB or more is recommended.

Pruned node has one big disadvantage. If you'd like to change your wallet (wallet.dat) it will be much longer to rescan because node will need to download missing part of the chain once again. It can take many hours or even days.

I agree that it is effectively a backup, but a backup is usually an inert copy. If both nodes are run at the same time using different computers, then that is what I consider to be a parallel node. Normally one wouldn't do this, but it can be useful for me where I have problems with battery storage. I'm reviewing this, and may drop the concept in the future, unless somebody can think of some other advantage.

Wallet is to store private key. The term full node or prune node (with Bitcoin Core) does not change the fact that wallet stores your bitcoin private key. What you called as a copy or parallel node is simply a backup of your wallet, just a different on how you run the wallet as full or prune node.

As long as your node (full or prune) is fully synced with the bitcoin network and you have access to the wallet password (in Core, developer call it as passphrase) you will be able to send your coins.

To receive, no need to sync wallet with network.

I'd like to introduce a node variant, and that is a copy or parallel node. At this moment,I have a full or archival node, and I am building a pruned node with a totally different wallet. These are on external  USB hard drives. I also have a copy of the wallet and blockchain associated with the "complete" node on yet another drive. I try to keep these up to date. I am assuming that I can send and receive coins from either of the parallel drives, although I haven't tested the sending yet.

You run two full nodes? How come and are they in the same location or one is work and one is home?

I have no intention of arguing, I'm just curious.

No. The nodes just need to delete the block files from your computer since it has basically gotten everything that it needs from the synchronization prior. The reverse is true however; you'll need to resynchronize if you want to disable pruning.

For future reference (for myself) -

I run two full nodes, if I was ever to get fed up with doing so & decided to change to prune node on one or both computers would I have to resync or download the entire blockchain from scratch?

Pruned nodes and Full nodes are essentially the same thing to the user, but it just isn't as useful to its peers than say a full node. The block data for a Bitcoin Core client is not necessary for it to operate and it isn't used by the client very often. Unless the user is importing a new address, the client has no reason to rescan the block data at all.

Pruned nodes provides the same security as a full node. They download and validate every single block but they discard those which is not needed. The size of the block data selected provides the client with a buffer in the case of a major reorg. But I don't foresee that being a big problem.
Both full nodes and pruned node downloads the entire blockchain.

I think this topic supposed to be Full Client Wallet and the Pruned Type of a Full Client Wallet. Full client wallet like bitcoin core download the whole bitcoin blockchain from the scratch to the recent time, but that is not the reason they run full node, they run full node by fulfulling the concesus rules. In the blockchain are blocks, the full nodes download the blocks and also including transactions that miners picked at certain time into each block at a specific time which is usually 10 minutes on average. If the prone node only download the blockchain of a specific recent time, that does not mean it will not run full nodes as long as it is fulfulling the concensus rules. So, both the full client wallet and the proned type of the full client wallet are running full nodes.

I use pruned type of the full client wallet because normally the wallet suppose to be full client, but not. Bcause only the recent blockchain is downloaded and not the entire bitcoin blockchain. But, both bitcoin core and the pruned bitcoin core are running on full nodes.

I am not an expert, this is what I have just learnt. This thread is so helpful.

some definitions in bitcoin aren't mature enough in my opinion and need more clarification or maybe even new terms to describe them.
one of them is full node. usually full node is also referred to as full verification node which refers to a node that fully verifies everything from the beginning and stores the UTXO set (there is no mention of storing blockchain). with that definition you can categorize a pruned node as a full node too since it also verifies everything and stores UTXO set.

eg. definition on https://en.bitcoin.it/wiki/Full_node doesn't even mention storage
"Any computer that connects to the Bitcoin network is called a node. Nodes that fully verify all of the rules of Bitcoin are called full nodes."

then it defines a new term "Archival Nodes" which are nodes that store and also broadcast old blocks.

I could be wrong but I totally agree with you on this.

SPV wallets, ie. do not store the full blockchain, instead they only store block headers (not the block transactions). Consequently, as you said, they don't have fully details on UTXOs, and there are risks of double spend with SPV wallets. To overcome such attacks, they have to connect to the other nodes, and should be honest nodes on the network in order to avoid terrible connections to fake nodes or wrong blockchains, not real blockchain of bitcoin.

In the other words, nodes are called as Full nodes (from my understandings) if they store the full blockchain, and therefore they have complete history of blockchain transactions (includes all UTXOs, as you said).

Prune nodes, despite of the fact that they download and sync with all blockchain database, but such nodes automatically truncate their database over time. The level of database truncation on prune nodes depends on the N parameter setup by users. The smaller N parameter, the more severity of database truncation.

Maybe someone will argue that prune node actually download the full blockchain, but the thing is download, sync, and store the full blockchain is very different. Full nodes always store the full blockchain at the last time point it synchronises with the network, whilst prune node always store the small part of the blockchain.

It depends on your definition of "full" and from my point of view a full node is something which stores the entire Blockchain including all past UTXOs as well as the complete database including mempool and past blocks. That is my definition of a full node because without help from others nodes it can return data from the current Blockchain and data from before the node was created. A prune node can gather information from other nodes about past block data but is not doing itself and relies on full nodes and its for that reason that full nodes are required to be run.

If you can afford the storage requirements of a full node the network will appreciate as many full nodes on the network as possible but a pruned node will still be beneficial to most of the network because it can still verify past transactions without storing them by using other nodes on the network and because it has all the UTXOs.

Pruning nodes do advertise to the rest of the network that they are just pruning nodes and don't have a full copy of the Blockchain which means theres no delays if you require a full blockchain. Every pruning node is different and the node operator is the one that is in charge of how much data is pruned which means that a pruned node could store up to 75% of the Blockchain if it wanted. So if you are limited for space but want to maximize the usage of your node by the network it is worth storing as much as possible.

Thank you.

To sum up, to run a prune node with minimum storage value (2GB), one need to have at least 3.5 GB - for chainstate + 2GB - for blocks + 52.1 MB for initial setup (image below).

---

Despite of there are some overlayed functionality between full node and prune node, they are different.

A full node means it has four functionalities at the same time: routing, complete blockchain database, mining, and wallet services.
Importantly, without the complete blockchain database, a prune node will never become a full node. But when someone set up the n parameter for prune node to the one of full node, it turns to be a full node, and no longer be a prune node. Unfortunately, it will become a full node shortly because when time goes longer, that n parameter will become less than the complete blockchain-size, and that node will be degraded to a prune node, again.

Prune node can be a mining node, I agree because a mining node theoritically comes from a full node (stores the complete blockchain) or a lightweight node (does not mandatorily store blockchain database, it depends on a pool server).

it is a bit odd to categorize pruned node this way as if it is different from a full node. specially when most things you included in your definition of a full node are shared between them:


1) a pruned node downloads the entire blockchain but only stores a small portion of it (from the end).
a pruned node Can also relay new transactions and new blocks and the old blocks that it has to other nodes (routing?)
a pruned node can also be used as the backend for mining and can be used as a wallet.
2) this is the only difference.
3) a pruned node can also do it by verifying the entire blockchain and the new blocks and transactions while rejecting anything invalid and relaying valid ones to other nodes.
4) you have the chainstate and can always use bloom filters to get your history so i don't think you technically need to resync from scratch if you imported a new wallet. although i have never done it with bitcoin core to see what happens.

It's not. That's the blocks dir (blocks only), you're forgetting the chainstate (which you need for a prune node too). It sits slightly over 3.5 GB for me on a full node now, thus you'd need at least 5 GB (3.5 GB chainstate + 2 GB blocks) of total storage for the pruned one.