1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <laanwj@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B2E610BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 15:06:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 820EF8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 15:06:03 +0000 (UTC)
Received: by mail-wm0-f50.google.com with SMTP id n5so84532030wmn.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 07:06:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to;
bh=fk/gXoMK6pahbnYN3yHgUJ31qA5t4ujjyzdYlWS9xL0=;
b=n8K54ct1ySpsOyg0X9vR4aAcbzy4g9MCLzC5iCrSENxMqsw931WDrVFr9Hfu189bmd
pVGJqbXmgE5kcGIDwsyvQhTxZMm4tp0ssZcbrlKiEGcjBoHZPHu7+jFxyUkxLBIL2PyC
5U2HC3xTlfnwlTWwCZse1b7pE3eY6FcCac5GJCQ8hZ1+L07kGEA7fblDZ5hy3DAhAYK1
V2wlsuDoiJ4TiV58rL7cnrTgl4Gc6xKcTHz/HVu6mBKnQfFNEZ4iud+D7KezyvNyOtOw
EP+EiBnFVc6/0hAN6sqnU9H2U35ARV+B0S1dWAFuC3HCriFX6n6NkmfI5seLe8rqXEcb
5rhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to;
bh=fk/gXoMK6pahbnYN3yHgUJ31qA5t4ujjyzdYlWS9xL0=;
b=en0ScJovZnBaA76mQtmo+Zs0q129JczG3ip65necukpx4rvEUyVclnpKOAHXfBlyaz
4ANnIBfx6UDrX89+CzbvplaItps8YMHM0t9zSVwYmTLcdBXN7k/uh09xMcJYXveJ1nHa
zWuHSHhbNBkqNPhR2dmwzTSbk9F5HTk9YjfScLBtAK+ueeHYfdwfrC2I4+dOQ49P88Nb
tIC09/Kfz9uDi1YZrNTbTTs+4FYxW+6qRG9v1XN90jkSvkOetu4tM3WmOlItVQ+5br0d
/OC8k7/zM+PoOG6TF8QeSAc/5Bq2ZKVsEXdFBG/pBbQ2ZwKpH9pozP3vC7KTuNXGtkk5
zNNw==
X-Gm-Message-State: AG10YOTbXTyjqxF7oyXp3T3wPc/jpEVr0SlS5KKyJHUy47tbOdrpGDZPvY7XIhy/fY0SBg==
X-Received: by 10.28.12.140 with SMTP id 134mr18040107wmm.21.1453734362212;
Mon, 25 Jan 2016 07:06:02 -0800 (PST)
Received: from amethyst.visucore.com (dhcp-089-098-228-253.chello.nl.
[89.98.228.253]) by smtp.gmail.com with ESMTPSA id
w17sm16572067wmw.15.2016.01.25.07.06.00
(version=TLS1_2 cipher=AES128-SHA bits=128/128);
Mon, 25 Jan 2016 07:06:01 -0800 (PST)
Date: Mon, 25 Jan 2016 16:05:59 +0100
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
To: xor@freenetproject.org
Message-ID: <20160125150559.GA28847@amethyst.visucore.com>
References: <20160117100808.GA4299@amethyst.visucore.com>
<1591452.8UA7xN1qih@1337h4x0r>
<20160125120317.GB17769@amethyst.visucore.com>
<2815165.aykQg88K5r@1337h4x0r>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2815165.aykQg88K5r@1337h4x0r>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2016 15:06:04 -0000
> > 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?
The term 'pruning', unfortunately is very much overused and overloaded in the
bitcoin ecosystem. Satoshi's paper refers to UTXO pruning. This is Pieter Wuille's "ultraprune",
which has been part of Bitcoin Core for more than three years.
Block pruning is not mentioned in that paper because it is just administrative,
the only reason that nodes store historical blocks at all is to serve it to other nodes,
as well as to catch up the wallet status and for -reindexes.
> Thus, it would be nice if you could yet once more edit the release notes to:
I don't have time to work on the release notes right now, but if someone else
wants to contribute that'd be awesome.
> - explain why a N must be given
To give a quotum. The point is that the user can choose how much harddisk space they want to
dedicate to block storage.
Block data that is stored can be used by other software, or potentially be
served to other nodes. The latter is not implemented at the moment - it would require
a change to the P2P protocol, thus right now pruning nodes don't serve block
data at all.
> - what a "safe" value of N is. I.e. how large must N be at least to not delete
> security-relevant stuff?
There is no security compromise with pruning. Any value of N is intended to be safe.
Very low values would delete undo data that may be necessary in a reorganization,
but this is prohibited by argument checks.
Release notes are not meant as a replacement or supplement for documentation.
The documentation for -prune is this:
-prune=<n>
Reduce storage requirements by pruning (deleting) old blocks. This mode
is incompatible with -txindex and -rescan. Warning: Reverting this
setting requires re-downloading the entire blockchain. (default: 0 =
disable pruning blocks, >550 = target size in MiB to use for block
files)
> - maybe mention if there is a "auto" setting for N to ensure that it choses a
> safe value on its own?
As said, there is no safe or unsafe value. The lowest acceptable value is just as safe
as storing everything.
Wladimir
|
