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
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <prabahy@gmail.com>) id 1WYJZj-0002vh-55
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 18:19:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.181 as permitted sender)
client-ip=209.85.160.181; envelope-from=prabahy@gmail.com;
helo=mail-yk0-f181.google.com;
Received: from mail-yk0-f181.google.com ([209.85.160.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WYJZT-0007Yk-5E
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 18:19:47 +0000
Received: by mail-yk0-f181.google.com with SMTP id 131so3841144ykp.26
for <bitcoin-development@lists.sourceforge.net>;
Thu, 10 Apr 2014 11:19:25 -0700 (PDT)
X-Received: by 10.236.126.43 with SMTP id a31mr3957971yhi.154.1397153965645;
Thu, 10 Apr 2014 11:19:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.156.85 with HTTP; Thu, 10 Apr 2014 11:19:05 -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>
From: Paul Rabahy <prabahy@gmail.com>
Date: Thu, 10 Apr 2014 14:19:05 -0400
Message-ID: <CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3005de66d1a36d04f6b44147
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
(prabahy[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 AC_DIV_BONANZA RAW: Too many divs in a row... spammy template
-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
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1WYJZT-0007Yk-5E
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 18:19:47 -0000
--20cf3005de66d1a36d04f6b44147
Content-Type: text/plain; charset=ISO-8859-1
You say UTXO commitments is "a strict reduction in security". If UTXO
commitments were rolled in as a soft fork, I do not see any new attacks
that could happen to a person trusting the committed UTXO + any remaining
blocks to catch up to the head.
I would imagine the soft fork to proceed similar to the following.
1. Miners begin including UTXO commitments.
2. Miners begin rejecting blocks with invalid UTXO commitments.
3. Miners begin rejecting blocks with no UTXO commitments.
To start up a fresh client it would follow the following.
1. Sync headers.
2. Pick a committed UTXO that is deep enough to not get orphaned.
3. Sync blocks from commitment to head.
I would argue that a client following this methodology is strictly more
secure than SPV, and I don't see any attacks that make it less secure than
a full client. It is obviously still susceptible to a 51% attack, but so is
the traditional block chain. I also do not see any sybil attacks that are
strengthened by this change because it is not modifying the networking code.
I guess if the soft fork happened, then miners began to not include the
UTXO commitment anymore, it would lower the overall network hash rate, but
this would be self-harming to the miners so they have an incentive to not
do it.
Please let me know if I have missed something.
On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
>
> 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
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--20cf3005de66d1a36d04f6b44147
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>You say =
UTXO commitments is "a strict reduction in security". If UTXO com=
mitments were rolled in as a soft fork, I do not see any new attacks that c=
ould happen to a person trusting the committed UTXO + any remaining blocks =
to catch up to the head.<br>
<br></div>I would imagine the soft fork to proceed similar to the following=
.<br></div>1. Miners begin including UTXO commitments.<br></div>2. Miners b=
egin rejecting blocks with invalid UTXO commitments.<br></div>3. Miners beg=
in rejecting blocks with no UTXO commitments.<br>
<br></div>To start up a fresh client it would follow the following.<br></di=
v>1. Sync headers.<br></div>2. Pick a committed UTXO that is deep enough to=
not get orphaned.<br></div>3. Sync blocks from commitment to head.<br>
<br></div>I would argue that a client following this methodology is strictl=
y more secure than SPV, and I don't see any attacks that make it less s=
ecure than a full client. It is obviously still susceptible to a 51% attack=
, but so is the traditional block chain. I also do not see any sybil attack=
s that are strengthened by this change because it is not modifying the netw=
orking code.<br>
<br></div><div>I guess if the soft fork happened, then miners began to not =
include the UTXO commitment anymore, it would lower the overall network has=
h rate, but this would be self-harming to the miners so they have an incent=
ive to not do it.<br>
</div><div><br></div>Please let me know if I have missed something.<br><div=
><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"mailto=
: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"><div class=3D"">
<br>
</div>As this is a suggestion that I think I've seen come up once a mon=
th<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><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Put Bad Developers to Shame<br>
Dominate Development with Jenkins Continuous Integration<br>
Continuously Automate Build, Test & Deployment<br>
Start a new project now. Try Jenkins in the cloud.<br>
<a href=3D"http://p.sf.net/sfu/13600_Cloudbees" target=3D"_blank">http://p.=
sf.net/sfu/13600_Cloudbees</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div></div>
--20cf3005de66d1a36d04f6b44147--
|
