Adjusting Prune value is possible?

[LucyFurr]

Can I change the prune value of my node that I currently set it to 550MB and wanted it to increase to 10 or 20GB?

As far as I read from old threads, yes it is possible and I need to change the new value and restart the core, so I can retain newer blocks upto the value I set but I just wanted to double-check before changing anything, and make sure I don’t mess up.

[LoyceV]

You can set it in the GUI under Options, or as a command line option (in MB):

Code:

-prune=20000

What's your reason for doing this? The only thing I can think of is to be able to load wallets that are several weeks old.

[Cookdata]

Can I change the prune value of my node that I currently set it to 550MB and wanted it to increase to 10 or 20GB?

As far as I read from old threads, yes it is possible and I need to change the new value and restart the core, so I can retain newer blocks upto the value I set but I just wanted to double-check before changing anything, and make sure I don’t mess up.

If you using Bitcoin core V28 upward, you can use the GUI to change it from  settings => Options =>Main =>prune block storage to= 10 or 20 and save but make sure to restart your Bitcoin node for the change to take effect.

There is nothing that is going to happen to your node, just that your node will keep the previous blocks you have validated and verified but as soon as it start to get new blocks and download them, once it reach your prune node size maybe 10GB, it will start to delete the previous ones and keep the recent ones to fit in blocks that will not exceed 10GB.

[promise444c5]

Yes you can but you won't  get any old block data as it's been deleted already, it will only be effective for future block data.
 So, If it's about previous data, forget it and keep using the current one. But if it's about you already freeing up some space, or you just felt like doing it to keep more data in the future, then go ahead..

[nc50lc]

As far as I read from old threads, yes it is possible and I need to change the new value and restart the core, so I can retain newer blocks upto the value I set but I just wanted to double-check before changing anything, and make sure I don’t mess up.

You probably found one or two threads with my reply.
Yes, it does and I tried it.

For your assurance, I reconfigured my v29.0 test pruned node to try the latest version:
Before (10240 MiB):

Code:

2025-08-05T06:16:54Z Config file arg: [main] prune="10240"
-snip-
2025-08-05T06:20:16Z UpdateTip: new best=0000000000000000000149935e5cf4a038cfe4a525a6ba1697d43be48d4b1946 height=908004 version=0x2c940000 log2_work=95.745036 tx=1220900700 date='2025-07-31T20:59:27Z' progress=0.998567 cache=57.7MiB(267993txo)

After (15240 MiB):

Code:

2025-08-05T06:23:43Z Config file arg: [main] prune="15240"
-snip-
2025-08-05T06:26:50Z UpdateTip: new best=00000000000000000001ff836520abb0e3403c5547c29e3bf7f2c622251cdb75 height=908686 version=0x2000e000 log2_work=95.753136 tx=1222508781 date='2025-08-05T06:22:21Z' progress=0.999999 cache=314.1MiB(2420866txo)

It synced to the current tip (908686) without any issue.

[apogio]

I must have created the exact same thread in the past.

I believe the general misunderstanding is whether increasing the prune size will actually re-download and restore deleted block files, or whether it will start downloading newer blocks from now on until it reaches the new prune size.

If I had to visualize it a bit better, it would look like this:

Case 1:
Before changing prune size: [------------ old deleted blocks ------------][---- current blocks saved ----][chaintip]
After changing prune size:   [-old deleted blocks-][---------------- current blocks saved ----------------][chaintip]

Case 2:
Before changing prune size: [------------ old deleted blocks ------------][---- current blocks saved ----][chaintip]
After changing prune size:   [------------ old deleted blocks ------------][------------ current blocks saved ------------][chaintip]

[LucyFurr]

Thanks everyone for the replies, now I changed into a higher value and the reason for this is not to rely on the peers to validate my recent transactions atleast that's a month old than just for the couple of days with the default 550.

It also helps the wallet load faster? not sure but I just want a bigger one and soon to have a full node but as of now just the pruned with more data stored.

[nc50lc]

Thanks everyone for the replies, now I changed into a higher value and the reason for this is not to rely on the peers to validate my recent transactions -snip-

Okay, but your full node (yes it's a "full node") in pruned mode isn't relying on your peers to verify your transactions.
It's just downloading from them but the verifications are done locally,
And your node still keeps related UTXOs saved even if the blocks where your recent transaction are already pruned..

It also helps the wallet load faster?

No, it wont affect its loading time positively nor negatively.

[LucyFurr]

~

Okay, Got it. I was under the impression that wallet need to redownload the data of UTXOs every time so thanks for clarifying it. Having a pruned node with more blocks stored got no benefit from the default value or has any?

[LoyceV]

Having a pruned node with more blocks stored got no benefit from the default value or has any?

See:

The only thing I can think of is to be able to load wallets that are several weeks old.

Side note: considering the questions you're asking, you could very well be better off with Electrum. Is there a reason you want to run a pruned Bitcoin Core node?

[apogio]

Side note: considering the questions you're asking, you could very well be better off with Electrum. Is there a reason you want to run a pruned Bitcoin Core node?

My convenience-oriented self would definitely agree. My privacy-oriented self still thinks Core is a good software wallet. For me the greatest disadvantage is the backup system. Core lacks an easy physical backup method unless you get the xpriv and print it using offline pc and like you say “an old classic cable printer”.

[nc50lc]

-snip-

Okay, Got it. I was under the impression that wallet need to redownload the data of UTXOs every time so thanks for clarifying it. Having a pruned node with more blocks stored got no benefit from the default value or has any?

Aside from Loyce's reply about being able to load a wallet that was last synced within your unpruned blocks.

You can still use rescanblockchain command with specified starting block height
So if you need to import a prvKey, xprv or xpub via importdescriptors command, you can scan more blocks than the default.
Useful if your target UTXO is just a few months old.

[LucyFurr]

Side note: considering the questions you're asking, you could very well be better off with Electrum. Is there a reason you want to run a pruned Bitcoin Core node?

Currently I am using Electrum and I used to have bitcoincore back a while ago without fully understanding what it is supposed to be and the curiosity woke up again after reading couple of threads here and there, am forcing myself again to have my own and explore it further. Also I barely use my data while paying for unlimited so an attempt to rip off my ISP.

[apogio]

Currently I am using Electrum and I used to have bitcoincore back a while ago without fully understanding what it is supposed to be and the curiosity woke up again after reading couple of threads here and there, am forcing myself again to have my own and explore it further. Also I barely use my data while paying for unlimited so an attempt to rip off my ISP.

So if you plan to have your Core as a node and connect Electrum to it, you're gonna need an electrum server, but for this you need a non-pruned node.

If you wanna use it as a wallet, you can use a pruned node with the minimum size because any wallet you will create after the initial blockchain download, it will be perfectly fine.

The only reason why you need a pruned node (in general) is space limitation. If you don't have or don't wanna waste disk space. For any other reason, you won't see any difference between having 1GB pruning size or 100GB pruning size.

The only difference will be that you will be able to load wallets that you had created deeper in the past. But if you don't have old wallets, then literally just use the minimum size of pruning (or no pruning at all) depending on your disk limitations.

[LucyFurr]

Currently I am using Electrum and I used to have bitcoincore back a while ago without fully understanding what it is supposed to be and the curiosity woke up again after reading couple of threads here and there, am forcing myself again to have my own and explore it further. Also I barely use my data while paying for unlimited so an attempt to rip off my ISP.

So if you plan to have your Core as a node and connect Electrum to it, you're gonna need an electrum server, but for this you need a non-pruned node.

Possibly in the future, but for now I want this mostly for learning and experimental purposes.

If you wanna use it as a wallet, you can use a pruned node with the minimum size because any wallet you will create after the initial blockchain download, it will be perfectly fine.

The only reason why you need a pruned node (in general) is space limitation. If you don't have or don't wanna waste disk space. For any other reason, you won't see any difference between having 1GB pruning size or 100GB pruning size.

The only difference will be that you will be able to load wallets that you had created deeper in the past. But if you don't have old wallets, then literally just use the minimum size of pruning (or no pruning at all) depending on your disk limitations.

Yes, it is only because of the disk limitation, my primary disk is 1TB nvme still I use my system for other things so I can't go for a full node with my current system unless I increase the primary disk. And a secondary disk is only possible through SATA ports and external disks, but I guess they're not suitable for the job so going with the pruned one now and maybe try to get a cheaper dedicated device to run 24/7.

[LoyceV]

Possibly in the future, but for now I want this mostly for learning and experimental purposes.

Why not use Testnet? Start Bitcoin Core with this option:

Code:

./bitcoin-qt -testnet4

It's much smaller to download, and meant for experimenting without risking any funds. See this post to get some testcoins.

[apogio]

Yes, it is only because of the disk limitation, my primary disk is 1TB nvme still I use my system for other things so I can't go for a full node with my current system unless I increase the primary disk. And a secondary disk is only possible through SATA ports and external disks, but I guess they're not suitable for the job so going with the pruned one now and maybe try to get a cheaper dedicated device to run 24/7.

Ok, so I suggest you keep the minimum amount of memory, there is no reason for anything larger. Also, take into consideration LoyceV's suggestion. A testnet Core instance will give you all the features of a mainnet instance, but with the additional feature that you won't be able to screw anything up and you will also be able to test literally everything, without having to spend money to do your tests.

[LucyFurr]

A testnet Core instance will give you all the features of a mainnet instance, but with the additional feature that you won't be able to screw anything up and you will also be able to test literally everything, without having to spend money to do your tests.

That should do the job even better, thanks for the suggestion guys. Since I already have the pruned mainnet, can I run testnet in parallel?

I read it is possible but one at a time not possible to have them simultaneously right?

A brief instruction can be helpful.

[LoyceV]

Since I already have the pruned mainnet, can I run testnet in parallel?

Yes, I've been doing that on my server for months.

I read it is possible but one at a time not possible to have them simultaneously right?

Just try it

[Cricktor]

If you want to run two Core instances, one for Mainnet and another for Testnet3 or Testnet4, you have to setup both Core to use separate ports or the Core started as second one will complain that some port is already in use.

IIRC, pretty hidden in the https://raspibolt.org instructions, funnily in the extras section of Lightning, there's a link to a description how to setup Mainnet and Testnet simultanously. It's not easy and isn't much for Windows users but it's possible to adapt once you understand the main details.

Here's the link: https://github.com/robclark56/RaspiBolt-Extras/blob/master/RB_extra_03.md

I will implement something like this for myself, too. As I've moved the Mainnet block storage of my non-pruned node to a second internal storage media, I've space again on the first internal SSD to have Testnet3 and/or Testnet4 in parallel. It's only that I need to find time to do it and spare time and mood to do it, is kind of a scarce thing. Don't hold your breath and I won't do it on Windows anyway... 

BTW, while Mainnet, see https://fork.observer/, has only occasional block branching...


Testnet4 on the contrary is quite a block branching mess...


and because of the mining timestamp shenanigans it takes most of the time 20min for confirmations and until the PoW-strongest chain-branch is established. (I didn't play a lot with Testnet4, but when I did, it was a little bit annoying.)