Exposing prune option in GUI

sime commented at 7:40 pm on July 21, 2015: contributor

With a pruned wallet possible in master I believe we should expose the option in the GUI.

The Main tab in preferences will offer a chance to toggle the node type and size.

The prune size UI should not permit sizes less than 550.

jonasschnelli commented at 7:45 pm on July 21, 2015: contributor

concept ACK.

ajweiss commented at 9:51 pm on July 21, 2015: contributor

There are a couple of considerations to take into account here:

This only prunes the blockstore, it does not keep disk usage beneath the pruning target. I think this should be called out a little more clearly.
The pruning target is just that, a target, sometimes the target will be overshot a bit. Maybe this can be alluded to in the UI, or maybe it’s for the release notes.
Enabling pruning essentially binds a given instance to its wallet. That is, once pruned, you can no longer import addresses, keys or wallets without a full resync. Since this is an hours long operation, I think there should probably be some warning.
Enabling pruning disables several node functions that support the network, such as historical block service and serving of proofs to SPV clients, most GUI users probably don’t care, but it’s a side effect.

While there are certainly differing opinions on this, I personally believe that the pruning feature at this stage is still somewhat experimental and has side effects that only people who are paying close attention will be aware of. With time, some of these side effects will go away or be minimized, but if there’s going to be a GUI element, I think it makes sense to call this out and direct the user to the release notes. If someone turns it on and it results in an unexpected multi-hour sync being required, that’s pretty bad UX.

Honestly, I’d err on the side of requiring the user to manually supply the option in the config file as I believe users that are willing to do this are more likely to have read the release notes and fully understand the ramifications of turning it on.

luke-jr commented at 10:32 pm on July 21, 2015: member

Probably it should be a button rather than a checkbox to signify the semi-irreversibility of the operation. For example, a button “Enable Pruning” which displays a dialogue box explaining all the risks/limitations of a pruned node (doesn’t contribute to the network, tied to the current wallet, etc), and asks for a confirmation.

jonasschnelli commented at 5:25 am on July 22, 2015: contributor

+1 for @luke-jr dialog box.

sipa commented at 5:26 am on July 22, 2015: member

Agree with Luke.

ajweiss commented at 3:01 pm on July 22, 2015: contributor

SGTM

laanwj added the label GUI on Jul 22, 2015

laanwj added the label Feature on Jul 28, 2015

rebroad commented at 6:01 am on October 19, 2016: contributor

@luke-jr What would be involved in making it less-irreversible? I.e. can it be coded (in another PR) to only re-download the pruned blocks rather than the whole blockchain?

fresheneesz commented at 2:45 am on December 23, 2017: none

What would be involved in making it less-irreversible?

Is it possible to use SPV to obtain a verified history of an item in the UTXO set?

only re-download the pruned blocks rather than the whole blockchain?

In the case of data loss of the UTXO set and pruned nodes, I would imagine if you kept a hash (or set of hashes) of those data sets you could request just the data you need to replace from other nodes in the network and could verify that they hash to the same values you have. In order for this to survive a HD failure they’d need to be stored on a different disk tho.

Sjors commented at 7:15 pm on March 16, 2018: member

Concept ACK. I just had to tell someone today that running a full node is easy, except if you don’t have 150 GB then you need to do this prune thing… This issue is a bit more urgent then when it was opened.

Even better would be for QT to propose a reasonable size at launch if it’s obvious the chain won’t fit on disk, but that could be a followup.

Agree with @ajweiss comments (1 & 2). I don’t think (3) is a problem for most users with only one wallet, but the UI could warn about potential downsides of pruning in an “are you sure” dialog and a tooltip. Also agree with @luke-jr that it should be made clear this is hard to reverse. The lack of contribution to the network situation has improved a bit since.

Related: #12404 or something like it should make IBD faster for pruned nodes.

What would be involved in making it less-irreversible?

Is it possible to use SPV to obtain a verified history of an item in the UTXO set?

It just requires a new blockchain download. Making that suck less seems of out of scope for this issue.

luke-jr commented at 9:45 pm on March 16, 2018: member

FWIW, Knots has had a GUI for pruning in the first-run dialog for a while. Getting that added to Core is blocked on #11082

Sjors commented at 3:31 pm on March 17, 2018: member

That’s a pretty big change. It’s true that unlike existing QT settings, prune must be persisted such that bitcoind also uses it. But it seems easier to just append it to bitcoin.conf. Two config files adds code complexity and isn’t a great user experience. If any potentially problematic other settings are found in that file, QT could prompt the user to manually set prune=.

luke-jr commented at 3:35 pm on March 17, 2018: member

There was resistance to modifying bitcoin.conf itself.

Sjors commented at 3:38 pm on March 17, 2018: member

If this is only used for prune then QT could simply refuse to modify any existing (non-empty) bitcoin.conf. We can get more bold after that.

luke-jr commented at 3:40 pm on March 17, 2018: member

I see no point in a hacky intermediate state that we will need to somehow upgrade from later. bitcoin_rw.conf works fine.

Sjors commented at 9:15 am on March 30, 2018: member

Another approach could be to change the meaning of a missing prune= setting. Currently that’s interpreted as prune=0 which will throw an error if the block database is actually pruned. What if instead we interpreted a missing setting as prune=1 if blocks are pruned, prune=0 if not pruned?

In that case, if a user enables pruning in QT and then runs bitcoind their chain would keep growing until either the next time they launch QT or until they explicitly set prune in bitcoin.conf.

This would allow us to kick the shared configuration file issue down the road (though I’d prefer to solve that).

Sjors commented at 2:35 pm on April 19, 2018: member

Implemented the other approach in #13029.

Sjors commented at 1:27 pm on April 20, 2018: member

Opened PR #13043 to add this setting to the GUI.

laanwj closed this on Jun 11, 2018

laanwj referenced this in commit 6e249e4678 on Jun 11, 2018

PastaPastaPasta referenced this in commit fdfbd01954 on May 11, 2020

MarcoFalke locked this on Sep 8, 2021

Exposing prune option in GUI #6461