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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <simon@coingyft.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 424C4DB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 15:57:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com
[209.85.192.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7690D79
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 15:57:56 +0000 (UTC)
Received: by mail-qg0-f41.google.com with SMTP id e32so112247936qgf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 07:57:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=coingyft-com.20150623.gappssmtp.com; s=20150623;
h=content-type:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=M1//lV98vuZBiheKT1HDp4q9nlJu+3V5E5zDNGkJX3g=;
b=vhasbyfhTdITAwycCxgtuXBYoDfMy3vAxneo4UGRI0IwrJ+8P4kPGYzNutOdN/UpxP
VSOKUYGwd3Nx6Msi55lqoGsczacaMERTbt5owuaxOdrJWHYruzzpy34Pn+Bw6r19xGU1
6vwp1iGYcXC4alPMJJCGQTl2thRwGUDK6ENDNedvAkA+tnVgdD07tcqL6ems0FBV23u8
Gts/LjjkrR6M3yocLS1N07EECnhg9J38c3MbFz17c6yb+fx5XjCZnYEZWkNTrZOboQgU
tlZG6xqHe9KGYVq6k0lstpKdF5QrLwrAQY34EkcNp8rEZ0Ige6GB7Gnog5j6W77vVaEb
EfuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:content-type:mime-version:subject:from
:in-reply-to:date:cc:content-transfer-encoding:message-id:references
:to; bh=M1//lV98vuZBiheKT1HDp4q9nlJu+3V5E5zDNGkJX3g=;
b=Xki+CgATTYxmBazAKhkvWCaTpWwmnYKf4h8lc9mfdlHjr37WQ5iIlqtQhqjbGckDbj
nuuV9fVrRTHnqEbxaOmDt14eyYck3w1CIBS+b2v/KCHwX4FYbr1nfLmbRsuF0TmjuJrd
ml82qWQLFMVvFy+ZweSlh3huX1bBTUgX8Oj1SV/uySNfYeSWrNX5UUYwEnk5Nh0M13+E
JUM78wVRArdOtqHdN5jsc82KpKoF2QRvcSxipUaqzEW4qVng+JzpdEB7VgRFoyhdDDh/
aDJ23W11pNEfLmRuTLR2MB88d0MJRvjQDoaj6yHc9FV11uJAGaeUwZx/a9zFZxK4t5en
eQKw==
X-Gm-Message-State: AG10YOTVphUHKYvmd/wi4pU0Ra6SltMpjSEG7XnnhjQc3j/yCvT6B64dERC3uJm+Gmc2Lg==
X-Received: by 10.140.134.197 with SMTP id 188mr23787248qhg.58.1453737475401;
Mon, 25 Jan 2016 07:57:55 -0800 (PST)
Received: from [192.168.2.140] (pool-100-0-197-194.bstnma.fios.verizon.net.
[100.0.197.194])
by smtp.gmail.com with ESMTPSA id l19sm724577qki.42.2016.01.25.07.57.54
(version=TLSv1/SSLv3 cipher=OTHER);
Mon, 25 Jan 2016 07:57:54 -0800 (PST)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Simon Selitsky <simon@coingyft.com>
X-Mailer: iPad Mail (13D15)
In-Reply-To: <20160125150559.GA28847@amethyst.visucore.com>
Date: Mon, 25 Jan 2016 10:57:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A118822-6550-4042-9229-1D213B6FE615@coingyft.com>
References: <20160117100808.GA4299@amethyst.visucore.com>
<1591452.8UA7xN1qih@1337h4x0r>
<20160125120317.GB17769@amethyst.visucore.com>
<2815165.aykQg88K5r@1337h4x0r>
<20160125150559.GA28847@amethyst.visucore.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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
X-Mailman-Approved-At: Mon, 25 Jan 2016 16:05:20 +0000
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:57:57 -0000
>> Block data that is stored can be used by other software, or potentially b=
e
>> served to other nodes. The latter is not implemented at the moment - it w=
ould require a change to the P2P protocol, thus right now pruning nodes don'=
t serve block data at all.
Why is the minimum storage quota of 550 MiB necessary for pruning nodes
if the block data is not served to other nodes ? Could the client just do tr=
ansaction verification and transaction relaying and only keep the block(s)=20=
being verified on disk ?
On Jan 25, 2016, at 10:05 AM, Wladimir J. van der Laan via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:
>>> To enable block pruning set prune=3D<N> on the command line or in
>>> bitcoin.conf, where N is the number of MiB to allot for raw block & undo=
>>> data.
>=20
>> =46rom having read the Bitcoin whitepaper quite a few months ago ago, I h=
ave the=20
>> very very basic understanding that pruning is meant to:
>> - delete old transaction data which merely "moves coins around"
>> - instead only store the "origin" (=3D block where coins were mined) and=20=
>> "current location" of the coins, i.e. the unspent transactions. Notably, I=
=20
>> understood it as "this is as secure as storing everything, since we know w=
here=20
>> the coins were created, and where they are".
>>=20
>> So from that point of view, I would assume that there is a "natural" amou=
nt of=20
>> megabytes which a fully pruned blockchain consists of: It would be define=
d by=20
>> the final amount of unspent coins.
>> I thereby am confused why it is possible to configure a number of megabyt=
es=20
>> "to allot for raw block & undo data". I would rather expect pruning just t=
o be=20
>> a boolean on/off flag, and the number of megabytes to be an automatically=
=20
>> 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 wo=
uld=20
>> delete "too much". I mean could this result in even security relevant=20
>> transaction data being deleted?
>=20
> The term 'pruning', unfortunately is very much overused and overloaded in t=
he
> bitcoin ecosystem. Satoshi's paper refers to UTXO pruning. This is Pieter W=
uille's "ultraprune",
> which has been part of Bitcoin Core for more than three years.
>=20
> Block pruning is not mentioned in that paper because it is just administra=
tive,
> the only reason that nodes store historical blocks at all is to serve it t=
o other nodes,
> as well as to catch up the wallet status and for -reindexes.
>=20
>> Thus, it would be nice if you could yet once more edit the release notes t=
o:
>=20
> I don't have time to work on the release notes right now, but if someone e=
lse
> wants to contribute that'd be awesome.
>=20
>> - explain why a N must be given
>=20
> To give a quotum. The point is that the user can choose how much harddisk s=
pace they want to
> dedicate to block storage.
>=20
> 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 wo=
uld require
> a change to the P2P protocol, thus right now pruning nodes don't serve blo=
ck
> data at all.
>=20
>> - what a "safe" value of N is. I.e. how large must N be at least to not d=
elete=20
>> security-relevant stuff?
>=20
> There is no security compromise with pruning. Any value of N is intended t=
o be safe.
>=20
> Very low values would delete undo data that may be necessary in a reorgani=
zation,
> but this is prohibited by argument checks.
>=20
> Release notes are not meant as a replacement or supplement for documentati=
on.
> The documentation for -prune is this:
>=20
> -prune=3D<n>
> Reduce storage requirements by pruning (deleting) old blocks. This m=
ode
> is incompatible with -txindex and -rescan. Warning: Reverting this
> setting requires re-downloading the entire blockchain. (default: 0 =3D=
> disable pruning blocks, >550 =3D target size in MiB to use for block=
> files)
>=20
>> - maybe mention if there is a "auto" setting for N to ensure that it chos=
es a=20
>> safe value on its own?
>=20
> As said, there is no safe or unsafe value. The lowest acceptable value is j=
ust as safe
> as storing everything.
>=20
> Wladimir
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
