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
|
Return-Path: <falke.marco@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 55249E0D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 14:44:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D44868A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 14:44:08 +0000 (UTC)
Received: by mail-io0-f172.google.com with SMTP id 1so153364598ion.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 06:44:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=OdcbhHBUKNMLI668QD5449VImvJpnCzSIHbe2kXj0RQ=;
b=iIs9TiNcPy29j/TfCgzuZgBpsTLDoejWcscpLI87dXkukfi+nsx4lolDSPelmtb5B4
U2EElaM1CdmYvokWZnx941pDc6nPBQQbYoz2zue1ZcJSt/sSyOPCnyD27U4KTGPUXegK
0QLG8q8Hake20rXGjbpSOiY4z9XY3aD6tPdqg//FrGmh+4cG+yeykilSiueq6nHvfQa/
3/NFin64CWA7xJ8RTk+ZJLzkRFFuN+VCQzKGIdNrfljrGr2DTfchnbdodVkU7NRTHzug
j8fq5a47RsccTBErgI3Awa18wfvQi7ItPtoYNPT4J94E5mfOXwTzYXvTJBL3QDVLf5MQ
bGsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:cc:content-type;
bh=OdcbhHBUKNMLI668QD5449VImvJpnCzSIHbe2kXj0RQ=;
b=PpZw2p45DkYs2Q1uB8pUdPLuFGRQ2UacYi0ZMXOMTMlRWaI7J4yvoaFEbLxi8JgB/f
kcv/z9TYMXkTU2/Sna0bU6a/tLlDjYggwJmT6Unug/9jil49uez3poQatlSQzFccT4GU
JXC1Fa+SgW9QD2KlTuluRLHltPRc0Ah9VCgkepIMlF3VOEnLoWCIi4lt9G++H97WzCMn
NtEd+Q9oe6l3lDDmMuHB0l9t9Kmzxqw/7O/YsjsuUCL46dRHK2eGjZy+bR5C6gyOOop/
kz6YfYMqwIoH/SfidiD7Pnt/PvRchBqR8Fk6ahnBkeOY0uPZaidW7iHTm3epIGVQ7nrt
zE3w==
X-Gm-Message-State: AG10YOT5yY2qclTL1wj6WkxMaOq76RFhq+KQvTBGOk6uod38KCeTK+Cia1vWRqDmE6XJV1Peu0md8CS7kCHQ2w==
MIME-Version: 1.0
X-Received: by 10.107.154.79 with SMTP id c76mr16367469ioe.53.1453733048274;
Mon, 25 Jan 2016 06:44:08 -0800 (PST)
Received: by 10.64.90.7 with HTTP; Mon, 25 Jan 2016 06:44:08 -0800 (PST)
In-Reply-To: <2815165.aykQg88K5r@1337h4x0r>
References: <20160117100808.GA4299@amethyst.visucore.com>
<1591452.8UA7xN1qih@1337h4x0r>
<20160125120317.GB17769@amethyst.visucore.com>
<2815165.aykQg88K5r@1337h4x0r>
Date: Mon, 25 Jan 2016 15:44:08 +0100
Message-ID: <CAKJqnrGq41ZvGByfH53n1=wJtPZghk+zyNOwZX8RXbJWcr=Xog@mail.gmail.com>
From: Marco Falke <falke.marco@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no 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:11 +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 14:44:09 -0000
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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
