Is it possible to change the prune value?

Is it doable to adjust the prune value on my node? Right now, I've got it set to 550MB, but I'm thinking about bumping it up to 10 or 20GB. From what I've gathered in some older discussions, it seems like I can indeed change it. I just need to update the value and restart the core to keep the newer blocks within the new limit. But I want to confirm this first before I go ahead and make any changes, just to avoid messing things up.

You can set it in the GUI under Options, or as a command line option (in MB): 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.

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.

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..

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): After (15240 MiB): It synced to the current tip (908686) without any issue.

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]

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.

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.. No, it wont affect its loading time positively nor negatively.

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?

See: 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”.

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.

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.

Possibly in the future, but for now I want this mostly for learning and experimental purposes. 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.

Why not use Testnet? Start Bitcoin Core with this option: It's much smaller to download, and meant for experimenting without risking any funds. See this post to get some testcoins.

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.

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.

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

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.)