What are the importance of running a full node?

[Accardo]

I came across the word "full node" today in this forum. While glancing through it on a bitcoin blog, the writer repeated this phrase "Helping the bitcoin network" severally.

My question as a newbie in bitcoin development is, how does the full nodes help the bitcoin network? Is it necessary for more volunteers to run on full nodes?

After reading on running a full node, It's quite interesting to run a full node. But the bandwidths and huge amount of space required to help this bitcoin network is too much for me at the moment.

I'll definitely run a full node, but your answers and explanation on the importance of running a full node matters to me.

Thanks.

[1715685657]

1715685657

[ranochigo]

My question as a newbie in bitcoin development is, how does the full nodes help the bitcoin network? Is it necessary for more volunteers to run on full nodes?

Full nodes helps to validate and relay information. In a sense, they do help to secure the network by minimizing the points of failure and adds to its redundancy. It's more beneficial for the individuals to run a full node because they'll be able to validate the information and be fully trustless. SPV clients like Electrum do not validate the entire block and trusts that the peers are feeding it honest info and that the work done by the honest portion of the network is more than those who are not.

After reading on running a full node, It's quite interesting to run a full node. But the bandwidths and huge amount of space required to help this bitcoin network is too much for me at the moment.

It definitely is. For most people, running a full node is definitely not the most important thing. If you want to use it as a wallet, you can still run it pruned and discard the unnecessary files; you'll still help the network by validating the blocks and the trustless aspect is not compromised. This still means that the synchronization process will take equal amount of time as well as bandwidth.

Tl;Dr: Running a node has more tangible benefits for the individuals than for the overall network.

[Accardo]

If you want to use it as a wallet, you can still run it pruned and discard the unnecessary files

So I can run a single node on a low spaced hard-disk? Should this be when installing the bitcoin core interface? Thanks

[ranochigo]

So I can run a single node on a low spaced hard-disk? Should this be when installing the bitcoin core interface? Thanks

Yep. The absolute minimum is 2GB. You can specify it anytime you run Bitcoin Core, just go to the preferences tab and you should see a checkbox.

You'll still help to relay newly mined blocks and transactions as well as the blocks that you've already stored in your disk.

[NotATether]

If you want to use it as a wallet, you can still run it pruned and discard the unnecessary files

So I can run a single node on a low spaced hard-disk? Should this be when installing the bitcoin core interface? Thanks

Keep in mind that full nodes have high bandwidth requirements. About 30GB of blocks needs to be downloaded monthly, and the entire blockchain which is about 300GB needs to be downloaded at first run. To save disk space you can enable pruning in bitcoin core, this throws away the blocks after it validates them causing the disk usage to be only around 2GB as ranochigo said (will be larger depending on how many blocks you retain, see below)

A normal full node also has to upload several hundred gigabytes of block data to other peers (my node with about 80 peers has uploaded 1.8TB in the past month). Because pruned nodes don't retain the blocks, they skip uploading them to peers, saving you all that upload bandwidth, but you still must sustain the download requirements.

To turn on pruning you need to type prune=N in your bitcoin.conf file, where N is at least 550 (keep the last 550 blocks on disk), 0 turns off pruning. It cannot be changed at runtime.

[ranochigo]

A normal full node also has to upload several hundred gigabytes of block data to other peers (my node with about 80 peers has uploaded 1.8TB in the past month). Because pruned nodes don't retain the blocks, they skip uploading them to peers, saving you all that upload bandwidth, but you still must sustain the download requirements.

Actually I think they still do? BIP159 does allow them to serve recent blocks (within the buffer) and those which are being relayed.

But yeah, they can still set an uploadtarget to limit the uploads in MB. You can change the prune within the UI btw: Settings>Options and it would work the same as if you would change the bitcoin.conf which I would imagine would be more newbie friendly.

[NotATether]

A normal full node also has to upload several hundred gigabytes of block data to other peers (my node with about 80 peers has uploaded 1.8TB in the past month). Because pruned nodes don't retain the blocks, they skip uploading them to peers, saving you all that upload bandwidth, but you still must sustain the download requirements.

Actually I think they still do? BIP159 does allow them to serve recent blocks (within the buffer) and those which are being relayed.

But yeah, they can still set an uploadtarget to limit the uploads in MB. You can change the prune within the UI btw: Settings>Options and it would work the same as if you would change the bitcoin.conf which I would imagine would be more newbie friendly.

You're right actually, it can still serve the last N blocks it has on disk. I would limit the number of peers it connects to instead, because each peer grabs more block and tx data, and setting maxuploadtarget alone when you have 30 or so peers will finish your bandwidth limit quickly, so your full node becomes less useful to query from.

If 80 peers uses 1.8TB upload (I think mine was running for three weeks), that translates to about 85GB per day or a little over 1GB/peer/day, that means if you limit the number of peers to 10, without setting maxuploadtarget, you only use slightly more than 10GB/day without restricting your connection to others at certain times of the day. I'm not sure if you can set maxconnections from the GUI though.

[ranochigo]

Running a full node definitely help Bitcoin network, assuming you allow incoming connection.

It does help the network more if you allow incoming connections. But isn't a connection (incoming/outgoing) still bidirectional?

Just by running a mode would strengthen the network by making it harder for sybil attacks already and an extra node validating the information being relayed. I think incoming connection would just help it a lot more.

[pooya87]

It does help the network more if you allow incoming connections. But isn't a connection (incoming/outgoing) still bidirectional?

it is but the communication will be limited to some extent when your node limits its contribution to the network. for example it won't accept any tx messages (no tx relay). also the node chooses who to connect or how many peers to connect to which could decrease the amount of traffic you spend.

[ranochigo]

Sure, but it's limited to validate and relay TX/block between nodes which accept incoming connection (which probably already receive the TX/block anyway). Additionally, most client limit outgoing connection to 8 nodes.

I get what both of you mean. But I think having an extra node (though not accepting incoming connections) still does bring a marginal benefit to both the user themselves and the network in general, though I can't really estimate the effectiveness of these against sybil attacks specifically. Though it is certainly, much much more beneficial to have one that accepts incoming connection.

Btw, isn't the TX relay mentioned by @pooya87 only applicable for blocksonly mode? Or has it changed, I'm still using 0.19.

[NotATether]

Btw, isn't the TX relay mentioned by @pooya87 only applicable for blocksonly mode? Or has it changed, I'm still using 0.19.

I think so but perhaps if you block all peers who are trying to connect to you, there will be no peers left to send tx messages to your node.

[ranochigo]

I think so but perhaps if you block all peers who are trying to connect to you, there will be no peers left to send tx messages to your node.

But you'll still receive and relay tx messages from other peers that you're connecting to. If not the wallet can't function as it can't see unconfirmed TXes. Hmm I might be missing something here.

[pooya87]

Btw, isn't the TX relay mentioned by @pooya87 only applicable for blocksonly mode? Or has it changed, I'm still using 0.19.

I think so but perhaps if you block all peers who are trying to connect to you, there will be no peers left to send tx messages to your node.

that is the point. you don't want to receive tx messages (among other things) to reduce the amount of data your node has to send/receive. your node just receives any new block that is found in full and updates its databases.

but @ranochigo is correct, this option is only enabled by using -blocksonly i was confusing it with something else.