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
|
Return-Path: <xor@freenetproject.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B5BFDFC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 12:27:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de
[80.67.31.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 651018A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 12:27:28 +0000 (UTC)
Received: from [77.178.123.142] (helo=anonymous)
by smtprelay03.ispgateway.de with esmtpsa
(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84)
(envelope-from <xor@freenetproject.org>) id 1aNgDQ-0001Vv-Ay
for bitcoin-dev@lists.linuxfoundation.org;
Mon, 25 Jan 2016 13:25:52 +0100
From: xor@freenetproject.org
To: bitcoin-dev@lists.linuxfoundation.org
Reply-To: xor@freenetproject.org
Date: Mon, 25 Jan 2016 13:27:18 +0100
Message-ID: <2815165.aykQg88K5r@1337h4x0r>
Organization: Freenet Project
User-Agent: KMail/4.13.3 (Linux/3.13.0-76-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <20160125120317.GB17769@amethyst.visucore.com>
References: <20160117100808.GA4299@amethyst.visucore.com>
<1591452.8UA7xN1qih@1337h4x0r>
<20160125120317.GB17769@amethyst.visucore.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6301928.ZivuVfnlPZ";
micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Df-Sender: eG9yQGZyZWVtYWlsLmJvZ2VydC5kZQ==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 13:15:32 +0000
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 12:27:29 -0000
--nextPart6301928.ZivuVfnlPZ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
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.
>=20
> Good idea, has been added by Marco Falke in commit fa31133,
Thanks. The RC2 changelog now says:
> 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 & u=
ndo
> data.
From=20having read the Bitcoin whitepaper quite a few months ago ago, I h=
ave the=20
very very basic understanding that pruning is meant to:
=2D delete old transaction data which merely "moves coins around"
=2D instead only store the "origin" (=3D block where coins were mined) an=
d=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 kno=
w where=20
the coins were created, and where they are".
So from that point of view, I would assume that there is a "natural" am=
ount of=20
megabytes which a fully pruned blockchain consists of: It would be defi=
ned by=20
the final amount of unspent coins.
I thereby am confused why it is possible to configure a number of megab=
ytes=20
"to allot for raw block & undo data". I would rather expect pruning jus=
t to be=20
a boolean on/off flag, and the number of megabytes to be an automatical=
ly=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 =
would=20
delete "too much". I mean could this result in even security relevant=20=
transaction data being deleted?
Thus, it would be nice if you could yet once more edit the release note=
s to:
=2D explain why a N must be given
=2D what a "safe" value of N is. I.e. how large must N be at least to not=
delete=20
security-relevant stuff?
=2D maybe mention if there is a "auto" setting for N to ensure that it ch=
oses a=20
safe value on its own?
Sorry if my descriptions are from a layman's point of view. I intention=
ally=20
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 su=
ch=20
stuff.
--nextPart6301928.ZivuVfnlPZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJWphSsAAoJEMtmZ+8tjWt5muQQAI2wK/BrEN9VAqJn18obeZOr
LLo3N3y9Iz3RXIZ5s3V0Q0l8F+7l55M5tZy4lgFQ5Y0n1G2md9kQKEgKFq0tNbC5
+D2zAemWZWZbQV91+t2WhKI4r8hKh/JuhNk1Bjiyt4IRI6LiaumoxPk/CSge7ifi
iSTh22TNhJ6thuEVaNjMTLRDxu1uf0CyxfTG427iz0Rj8MASCQrt81wnGH5RA+LB
QXGye8avaosVKvTs+gTAnW6eBI/muFh0uLrDUNpc4xwrmn1ejt+FfHgBGjiNK+fi
iF8brEonxzI0e0Ynu/kyaUkbrhIKNM5lPHBIbHAzWtAapZBGZYh0N/hHsPKJZCcf
clidX+TvmolbhKjbxKducSmJAA19Z9zBxWgUkatpAJK7DtloX52zpdOISA8av2ZI
MC7/qroTAfgOj4pKYUUY6t/ZNFGr99m10R/KBkuwWmq5IiolppqFLEZ+9ZIZTSpU
sLH0TOssCYaob4aOXR5ucYWrnSy8HbrHvlJ24ZNnx/3CsxSLAPo8JtgBbw6mnbrf
K2kcrwn2Zz4ofdXl32L15BYb3UNgGuKyo8Lsn2q2or0jyx5S+1WKNSHTPsMymrOE
tWAeQv/R0UyQXFXMPvAl2Y7Wh3SpV2I3MCSby5bcwa4dW3O6dneaQCEvAyMcVvRu
omHzx23XDM4ay9b5TJQ/
=5S1H
-----END PGP SIGNATURE-----
--nextPart6301928.ZivuVfnlPZ--
|
