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
205
206
207
208
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <brianchoffman@gmail.com>) id 1WYIQn-0007Vf-Io
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 17:06:29 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.53 as permitted sender)
client-ip=209.85.160.53; envelope-from=brianchoffman@gmail.com;
helo=mail-pb0-f53.google.com;
Received: from mail-pb0-f53.google.com ([209.85.160.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WYIQm-0007d7-LR
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 17:06:29 +0000
Received: by mail-pb0-f53.google.com with SMTP id rp16so4211796pbb.12
for <bitcoin-development@lists.sourceforge.net>;
Thu, 10 Apr 2014 10:06:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.66.161.69 with SMTP id xq5mr20997360pab.62.1397149582791;
Thu, 10 Apr 2014 10:06:22 -0700 (PDT)
Received: by 10.70.89.237 with HTTP; Thu, 10 Apr 2014 10:06:22 -0700 (PDT)
In-Reply-To: <CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
References: <CANEZrP04O7EqB=TqyTiC7O1K2A9R0nKJ_ssANHKg=Byum8-LtA@mail.gmail.com>
<CA+s+GJDbYjwhpsV15a+7kCO_vTstEewVrwvqbnB=a5zOSwFC6Q@mail.gmail.com>
<CAAS2fgStmEpiUV4Yh-qqu6sZ+VZ5SiQPwp+QA=3X5zR52ia3OA@mail.gmail.com>
<CA+s+GJBxEC2MifJQY5-vn2zSOHo-UOm8B1vYHHOfuxq26=VscQ@mail.gmail.com>
<CAADm4BDDJkS_xdjUn=2Yzs4B0RXTvpzpd5Z_kDRorzrn1HWSng@mail.gmail.com>
<CANEZrP1rPZYkTLmx5GOdj67oQAgFjeaF-LCKAXpg5XsEhXYFuQ@mail.gmail.com>
<CAADm4BB8y=k_f7CG3tyX6ruWF0w3+hU2Szv7ajLp1x7KhS56GA@mail.gmail.com>
<CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
Date: Thu, 10 Apr 2014 13:06:22 -0400
Message-ID: <CAADm4BB_JS8-tWi8bhUsuye6JpdrFciBxbNki67AV+U5rxX5jA@mail.gmail.com>
From: Brian Hoffman <brianchoffman@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b6dd002949a1c04f6b33c04
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(brianchoffman[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WYIQm-0007d7-LR
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Chain pruning
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 17:06:29 -0000
--047d7b6dd002949a1c04f6b33c04
Content-Type: text/plain; charset=UTF-8
Ok I think I've got a good understanding of where we're at now. I can
promise that the next person to waste your time in 30 days will not be me.
I'm pleasantly surprised to see a community that doesn't kickban newcomers
and takes the time to explain (re-explain) concepts.
Hoping to add *beneficial* thoughts in the future!
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman <brianchoffman@gmail.com>
> wrote:
> > Looks like only about ~30% disk space savings so I see your point. Is
> there
> > a critical reason why blocks couldn't be formed into "superblocks" that
> are
> > chained together and nodes could serve a specific superblock, which
> could be
> > pieced together from different nodes to get the full blockchain? This
> would
> > allow participants with limited resources to serve full portions of the
> > blockchain rather than limited pieces of the entire blockchain.
>
> As this is a suggestion that I think I've seen come up once a month
> for the past 3 years, let's try to answer it thoroughly.
>
> The actual "state" of the blockchain is the UTXO set (stored in
> chainstate/ by the reference client). It's the set of all unspent
> transaction outputs at the currently active point in the block chain.
> It is all you need for validating future blocks.
>
> The problem is, you can't just give someone the UTXO set and expect
> them to trust it, as there is no way to prove that it was the result
> of processing the actual blocks.
>
> As Bitcoin's full node uses a "zero trust" model, where (apart from
> one detail: the order of otherwise valid transactions) it never
> assumes any data received from the outside it valid, it HAS to see the
> previous blocks in order to establish the validity of the current UTXO
> set. This is what initial block syncing does. Nothing but the actual
> blocks can provide this data, and it is why the actual blocks need to
> be available. It does not require everyone to have all blocks, though
> - they just need to have seen them during processing.
>
> A related, but not identical evolution is merkle UTXO commitments.
> This means that we shape the UTXO set as a merkle tree, compute its
> root after every block, and require that the block commits to this
> root hash (by putting it in the coinbase, for example). This means a
> full node can copy the chain state from someone else, and check that
> its hash matches what the block chain commits to. It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).
>
> In essence, combining both ideas means you get "superblocks" (the UTXO
> set is essentially the summary of the result of all past blocks), in a
> way that is less-than-currently-but-perhaps-still-acceptably-validated.
>
> --
> Pieter
>
--047d7b6dd002949a1c04f6b33c04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ok I think I've got a good understanding of where we&#=
39;re at now. I can promise that the next person to waste your time in 30 d=
ays will not be me. I'm pleasantly surprised to see a community that do=
esn't kickban newcomers and takes the time to explain (re-explain) conc=
epts.=C2=A0<div>
<br></div><div>Hoping to add *beneficial* thoughts in the future!</div></di=
v><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Apr=
10, 2014 at 12:59 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailt=
o:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffm=
an <<a href=3D"mailto:brianchoffman@gmail.com">brianchoffman@gmail.com</=
a>> wrote:<br>
> Looks like only about ~30% disk space savings so I see your point. Is =
there<br>
> a critical reason why blocks couldn't be formed into "superbl=
ocks" that are<br>
> chained together and nodes could serve a specific superblock, which co=
uld be<br>
> pieced together from different nodes to get the full blockchain? This =
would<br>
> allow participants with limited resources to serve full portions of th=
e<br>
> blockchain rather than limited pieces of the entire blockchain.<br>
<br>
As this is a suggestion that I think I've seen come up once a month<br>
for the past 3 years, let's try to answer it thoroughly.<br>
<br>
The actual "state" of the blockchain is the UTXO set (stored in<b=
r>
chainstate/ by the reference client). It's the set of all unspent<br>
transaction outputs at the currently active point in the block chain.<br>
It is all you need for validating future blocks.<br>
<br>
The problem is, you can't just give someone the UTXO set and expect<br>
them to trust it, as there is no way to prove that it was the result<br>
of processing the actual blocks.<br>
<br>
As Bitcoin's full node uses a "zero trust" model, where (apar=
t from<br>
one detail: the order of otherwise valid transactions) it never<br>
assumes any data received from the outside it valid, it HAS to see the<br>
previous blocks in order to establish the validity of the current UTXO<br>
set. This is what initial block syncing does. Nothing but the actual<br>
blocks can provide this data, and it is why the actual blocks need to<br>
be available. It does not require everyone to have all blocks, though<br>
- they just need to have seen them during processing.<br>
<br>
A related, but not identical evolution is merkle UTXO commitments.<br>
This means that we shape the UTXO set as a merkle tree, compute its<br>
root after every block, and require that the block commits to this<br>
root hash (by putting it in the coinbase, for example). This means a<br>
full node can copy the chain state from someone else, and check that<br>
its hash matches what the block chain commits to. It's important to<br>
note that this is a strict reduction in security: we're now trusting<br=
>
that the longest chain (with most proof of work) commits to a valid<br>
UTXO set (at some point in the past).<br>
<br>
In essence, combining both ideas means you get "superblocks" (the=
UTXO<br>
set is essentially the summary of the result of all past blocks), in a<br>
way that is less-than-currently-but-perhaps-still-acceptably-validated.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span></blockquote></div><br></div>
--047d7b6dd002949a1c04f6b33c04--
|
