📅 Original date posted:2016-01-25
📝 Original message:All of this is already implemented in the bitcoind and bitcoin gui.
The theoretic minimum for the prune target would be 0 (just the header
of the current best block) as Bitcoin Core already stores the
chainstate (about 2 GiB) regardless of what you set for -prune=<N>.
In practice, the minimum is 510, so reorgs and small rescans (may not
be implemented in 0.12) are still possible.
The clients won't let you set it below that target:
"Prune configured below the minimum of 550 MiB. Please use a higher number."
Also, keep in mind Bitcoin Core comes with a help message explaining
-prune and other command line options
--Marco
2016-01-25 13:27 GMT+01:00 xor--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>:
> On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:
>> > If yes, I would highly recommend advertising it in the new release notes -
>> > as said, the disk space reduction is a big deal.
>>
>> Good idea, has been added by Marco Falke in commit fa31133,
>
> Thanks. The RC2 changelog now says:
>
>> To enable block pruning set prune=<N> on the command line or in
>> bitcoin.conf, where N is the number of MiB to allot for raw block & undo
>> data.
>
> From having read the Bitcoin whitepaper quite a few months ago ago, I have the
> very very basic understanding that pruning is meant to:
> - delete old transaction data which merely "moves coins around"
> - instead only store the "origin" (= block where coins were mined) and
> "current location" of the coins, i.e. the unspent transactions. Notably, I
> understood it as "this is as secure as storing everything, since we know where
> the coins were created, and where they are".
>
> So from that point of view, I would assume that there is a "natural" amount of
> megabytes which a fully pruned blockchain consists of: It would be defined by
> the final amount of unspent coins.
> I thereby am confused why it is possible to configure a number of megabytes
> "to allot for raw block & undo data". I would rather expect pruning just to be
> a boolean on/off flag, and the number of megabytes to be an automatically
> computed result from the natural size of the dataset.
> And especially, I fear that I could set N too low, and as a result, it would
> delete "too much". I mean could this result in even security relevant
> transaction data being deleted?
>
> Thus, it would be nice if you could yet once more edit the release notes to:
> - explain why a N must be given
> - what a "safe" value of N is. I.e. how large must N be at least to not delete
> security-relevant stuff?
> - maybe mention if there is a "auto" setting for N to ensure that it choses a
> safe value on its own?
>
> Sorry if my descriptions are from a layman's point of view. I intentionally
> did *not* re-read the Bitcoin whitepaper to have a better understanding:
> I think having a layman's understanding is a good usability test for such
> stuff.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Marco Falke [ARCHIVE] /
npub1qs…9jjz5
2023-06-07 17:47:55
in reply to nevent1q…ee3x
Author Public Key
npub1qspcss06rhl7lwrhzrnv5k7w7er32htkgds2d50802eguajx4p5sp9jjz5Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:47:55Event JSON
{
"id": "e971807dc56be1234e0ea5e332a81be8ef1d4d298dc79d352486179ea9e09865",
"pubkey": "04038841fa1dffefb87710e6ca5bcef647155d764360a6d1e77ab28e7646a869",
"created_at": 1686160075,
"kind": 1,
"tags": [
[
"e",
"a2c5e8a8812a1fbb64bafec18efd3012d3b028a825e407ccb16effdc61bfee78",
"",
"root"
],
[
"e",
"4cf6eb77faedf860f0622a590ecf258ed2d0e3719340d77202ac5b807f4abe14",
"",
"reply"
],
[
"p",
"9d769154ae3981ed1b1ae129497c5226ed13a094fc1d82fc60b4000e54dfeefd"
]
],
"content": "📅 Original date posted:2016-01-25\n📝 Original message:All of this is already implemented in the bitcoind and bitcoin gui.\n\nThe theoretic minimum for the prune target would be 0 (just the header\nof the current best block) as Bitcoin Core already stores the\nchainstate (about 2 GiB) regardless of what you set for -prune=\u003cN\u003e.\n\nIn practice, the minimum is 510, so reorgs and small rescans (may not\nbe implemented in 0.12) are still possible.\n\nThe clients won't let you set it below that target:\n\"Prune configured below the minimum of 550 MiB. Please use a higher number.\"\n\nAlso, keep in mind Bitcoin Core comes with a help message explaining\n-prune and other command line options\n\n--Marco\n\n2016-01-25 13:27 GMT+01:00 xor--- via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:\n\u003e\u003e \u003e If yes, I would highly recommend advertising it in the new release notes -\n\u003e\u003e \u003e as said, the disk space reduction is a big deal.\n\u003e\u003e\n\u003e\u003e Good idea, has been added by Marco Falke in commit fa31133,\n\u003e\n\u003e Thanks. The RC2 changelog now says:\n\u003e\n\u003e\u003e To enable block pruning set prune=\u003cN\u003e on the command line or in\n\u003e\u003e bitcoin.conf, where N is the number of MiB to allot for raw block \u0026 undo\n\u003e\u003e data.\n\u003e\n\u003e From having read the Bitcoin whitepaper quite a few months ago ago, I have the\n\u003e very very basic understanding that pruning is meant to:\n\u003e - delete old transaction data which merely \"moves coins around\"\n\u003e - instead only store the \"origin\" (= block where coins were mined) and\n\u003e \"current location\" of the coins, i.e. the unspent transactions. Notably, I\n\u003e understood it as \"this is as secure as storing everything, since we know where\n\u003e the coins were created, and where they are\".\n\u003e\n\u003e So from that point of view, I would assume that there is a \"natural\" amount of\n\u003e megabytes which a fully pruned blockchain consists of: It would be defined by\n\u003e the final amount of unspent coins.\n\u003e I thereby am confused why it is possible to configure a number of megabytes\n\u003e \"to allot for raw block \u0026 undo data\". I would rather expect pruning just to be\n\u003e a boolean on/off flag, and the number of megabytes to be an automatically\n\u003e computed result from the natural size of the dataset.\n\u003e And especially, I fear that I could set N too low, and as a result, it would\n\u003e delete \"too much\". I mean could this result in even security relevant\n\u003e transaction data being deleted?\n\u003e\n\u003e Thus, it would be nice if you could yet once more edit the release notes to:\n\u003e - explain why a N must be given\n\u003e - what a \"safe\" value of N is. I.e. how large must N be at least to not delete\n\u003e security-relevant stuff?\n\u003e - maybe mention if there is a \"auto\" setting for N to ensure that it choses a\n\u003e safe value on its own?\n\u003e\n\u003e Sorry if my descriptions are from a layman's point of view. I intentionally\n\u003e did *not* re-read the Bitcoin whitepaper to have a better understanding:\n\u003e I think having a layman's understanding is a good usability test for such\n\u003e stuff.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "314fd3bfc4d4288682b14879459d82044f9bc870a1a25b77d0e8f02fc41d39c4af5cd2f907af07902a8949732ea810ccbdcf9ed165ee7e065104b65ce8d0b27c"
}