-
Notifications
You must be signed in to change notification settings - Fork 35.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RfC: increase minimum prune target? #30037
Comments
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):
I would recommend we minimize impact to existing nodes and provide time for warning/deprecation.
This seems like a no-go to me as it can impact node runtime. An alternate option is presented below
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.
Yes, this seems prudent.
We should do something, as this seems like a bug given current allowed block sizes. How about something like:
|
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
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.
Sounds reasonable to me in general. |
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.
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.
|
The minimum pruning target of
550MiB
was chosen based on a physical block size of1 MiB
, seebitcoin/src/validation.h
Lines 69 to 76 in f5b6f62
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
and900 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
bitcoin.conf
to be able to start bitcoind.-prune
doc that values around 550MiB are pointless.The text was updated successfully, but these errors were encountered: