RfC: increase minimum prune target? about bitcoin HOT 3 OPEN

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

from bitcoin.

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.

from bitcoin.

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.

from bitcoin.