📅 Original date posted:2016-01-25
📝 Original message: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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/87785117/attachment.sig>;
xor at freenetproject.org [ARCHIVE] /
npub1n4…t6mlq
2023-06-07 17:47:54
in reply to nevent1q…ju3w
Author Public Key
npub1n4mfz49w8xq76xc6uy55jlzjymk38gy5lswc9lrqksqqu4xlam7sft6mlqPublished at
2023-06-07 17:47:54Event JSON
{
"id": "4cf6eb77faedf860f0622a590ecf258ed2d0e3719340d77202ac5b807f4abe14",
"pubkey": "9d769154ae3981ed1b1ae129497c5226ed13a094fc1d82fc60b4000e54dfeefd",
"created_at": 1686160074,
"kind": 1,
"tags": [
[
"e",
"a2c5e8a8812a1fbb64bafec18efd3012d3b028a825e407ccb16effdc61bfee78",
"",
"root"
],
[
"e",
"9fc1c8b24b43ffd2bd4f9a314af4db1d61c5a348f589ab2db407b4a15eb02818",
"",
"reply"
],
[
"p",
"5c0b7fca51fd4830b4d9f840de063faebeeabd3bb5dd118de9cdf50a6feaaf98"
]
],
"content": "📅 Original date posted:2016-01-25\n📝 Original message:On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:\n\u003e \u003e If yes, I would highly recommend advertising it in the new release notes -\n\u003e \u003e as said, the disk space reduction is a big deal.\n\u003e \n\u003e Good idea, has been added by Marco Falke in commit fa31133,\n\nThanks. The RC2 changelog now says:\n\n\u003e To enable block pruning set prune=\u003cN\u003e on the command line or in\n\u003e bitcoin.conf, where N is the number of MiB to allot for raw block \u0026 undo\n\u003e data.\n\nFrom having read the Bitcoin whitepaper quite a few months ago ago, I have the \nvery very basic understanding that pruning is meant to:\n- delete old transaction data which merely \"moves coins around\"\n- instead only store the \"origin\" (= block where coins were mined) and \n\"current location\" of the coins, i.e. the unspent transactions. Notably, I \nunderstood it as \"this is as secure as storing everything, since we know where \nthe coins were created, and where they are\".\n\nSo from that point of view, I would assume that there is a \"natural\" amount of \nmegabytes which a fully pruned blockchain consists of: It would be defined by \nthe final amount of unspent coins.\nI thereby am confused why it is possible to configure a number of megabytes \n\"to allot for raw block \u0026 undo data\". I would rather expect pruning just to be \na boolean on/off flag, and the number of megabytes to be an automatically \ncomputed result from the natural size of the dataset.\nAnd especially, I fear that I could set N too low, and as a result, it would \ndelete \"too much\". I mean could this result in even security relevant \ntransaction data being deleted?\n\nThus, it would be nice if you could yet once more edit the release notes to:\n- explain why a N must be given\n- what a \"safe\" value of N is. I.e. how large must N be at least to not delete \nsecurity-relevant stuff?\n- maybe mention if there is a \"auto\" setting for N to ensure that it choses a \nsafe value on its own?\n\nSorry if my descriptions are from a layman's point of view. I intentionally \ndid *not* re-read the Bitcoin whitepaper to have a better understanding:\nI think having a layman's understanding is a good usability test for such \nstuff.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 836 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/87785117/attachment.sig\u003e",
"sig": "8d0c9b53f6fee3043eeb7f0764075454af0f212398fde8923a185350f461f299d0b438febba146d3a1721e556cddee45023777c34b5b28f5c8d281d920a95efe"
}