RfC: increase minimum prune target?

[mzumsande]

The minimum pruning target of 550MiB was chosen based on a physical block size of 1 MiB, see 

bitcoin/src/validation.h

Lines 69 to 76 in f5b6f62

	// Require that user allocate at least 550 MiB for block & undo files (blk???.dat and rev???.dat)
	// At 1MB per block, 288 blocks = 288MB.
	// Add 15% for Undo data = 331MB
	// Add 20% for Orphan block rate = 397MB
	// We want the low water mark after pruning to be at least 397 MB and since we prune in
	// full block file chunks, we need the high water mark which triggers the prune to be
	// one 128MB block file + added 15% undo data = 147MB greater for a total of 545MB
	// Setting the target to >= 550 MiB will make it likely we can respect the target.

We never prune files within 288 blocks from the tip, so the size limit will not be respected if these blocks take up more space.

Since physical block sizes have increased since segwit, I think that there is no benefit to choosing -prune=550 as opposed to -prune=1000:
Running with the smaller value will likely slow down IBD a bit (because we prune / flush chainstate more often), but once we are getting closer to the tip, the blockfile directory will be between 700MiB and 900 MiB, so we'll need more disk space eventually anyway (also, today's chainstate is > 12 GiB, which is large in comparison).

So I wonder if we should

• increase the limit in a hard way - this would be an inconvenience to lots of existing users who would need to update their bitcoin.conf to be able to start bitcoind.
• increase it in a soft way, something like disrepecting it on purpose by setting it to a higher value, but without an init error.
• add a comment to the -prune doc that values around 550MiB are pointless.
• do nothing

[tdb3]

Great find!

It seems reasonable and safer to increase the min prune target, since blocks can be larger post-segwit (and we've seen it, e.g. 774628). Some rough napkin math for a new value (correct me if something looks off):

• 4MB per block, 288 blocks = 1152MB
• Add 15% for Undo data = 1325MB
• Add 20% for Orphan block rate = 1590MB
• Add one block file + added 15% undo data = 147MB
• Target >= 1737MB, so something like 1750MB seems at first glance that it could work

I would recommend we minimize impact to existing nodes and provide time for warning/deprecation.

increase the limit in a hard way - this would be an inconvenience to lots of existing users who would need to update their bitcoin.conf to be able to start bitcoind

This seems like a no-go to me as it can impact node runtime. An alternate option is presented below

increase it in a soft way, something like disrepecting it on purpose by setting it to a higher value, but without an init error.

This seems at minimum unintuitive and at most dangerous for node operators, since nodes with limited space would believe bitcoind was being limited/constrained to a particular allocated amount of space but would be exceeding the allocated amount.

add a comment to the -prune doc that values around 550MiB are pointless.

Yes, this seems prudent.

do nothing

We should do something, as this seems like a bug given current allowed block sizes.

How about something like:

• Temporarily allow and respect values >= 550MB (e.g. for one release)
• bitcoind provides a warning message for values between 550MB and 1750MB
• Add a clear deprecation warning in the release notes
• Add note/comment for prune in the default bitcoin.conf and -prune help/doc about values between 550MB and 1750MB being supported temporarily but unsupported in a future release, and that actual consumed storage may approach 1750MB even if 550MB is specified.
• In a future release, the min prune target can be changed to and enforced to 1750MB

[mzumsande]

since nodes with limited space would believe bitcoind was being limited/constrained to a particular allocated amount of space but would be exceeding the allocated amount

This is already the case today, because the 288 blocks rule takes precedence over the user-provided number. With average block sizes of 1.6MiB currently, my synced prune=550 node usually takes up between 700MiB and 900MiB of space for *.blk and *.rev files.. The target is only respected when possible (during the earlier parts of IBD where blocks are still small). So the point would be that if we are going to disrepect the target anyway in later stages of IBD we might as well start earlier (and gain some performance benefits).

Temporarily allow and respect values >= 550MB but < 1750MB (e.g. for one release)

You probably didn't mean it that way , but there is no maximum target, everything >=550MB is respected today, and we won't want to change that.

How about something like:

Sounds reasonable to me in general.

[tdb3]

since nodes with limited space would believe bitcoind was being limited/constrained to a particular allocated amount of space but would be exceeding the allocated amount

This is already the case today, because the 288 blocks rule takes precedence over the user-provided number. With average block sizes of 1.6MiB currently, my synced prune=550 node usually takes up between 700MiB and 900MiB of space for *.blk and *.rev files.. The target is only respected when possible (during the earlier parts of IBD where blocks are still small). So the point would be that if we are going to disrepect the target anyway in later stages of IBD we might as well start earlier (and gain some performance benefits).

Maybe a good way to handle this is to include/enhance a warning (described above) to let the user know that actual consumed storage can be greater (e.g. up to 1750MB) even if 550MB is specified.

Temporarily allow and respect values >= 550MB but < 1750MB (e.g. for one release)

You probably didn't mean it that way , but there is no maximum target, everything >=550MB is respected today, and we won't want to change that.

Correct, thanks for clarifying. I should have been more accurate in describing it, and have adjusted the description above. The overall idea is that in the interim we could be allowing/forgiving of values greater than 550MB but less than 1750MB. Values < 550MB cause init failure. In the interim all values >= 550MB are allowed. At some point later, only values >= 1750MB are allowed.

How about something like:

Sounds reasonable to me in general.