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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F1BC93E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 20:53:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 455821FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 20:53:53 +0000 (UTC)
Received: by lagc2 with SMTP id c2so133135000lag.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 13:53:51 -0700 (PDT)
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:to
:cc:content-type;
bh=dcpuKHl4hMlwZjhhLbu6IgomfJiWRmWS2qTqAnahbEs=;
b=dJqGPbECzVXpGQ3zCyZzd8p20MPLK1nn/EAZNgA/TXXSSUx0AJYvORkYwPM8exbfKx
A97LzRgR7u0VwGe50OrSW4zkSQAVkS4PKJXjniZuD+c2DR6+elb9gKHP4HuPa+7uKC/f
pRIyEpjC/4FlOaXlw7VuZJZUG44YFoOb2oDU3vECmo6xLZbhxGmQ5TuF8F1zy0KHWHsr
H4aBi+lnFxLQ3LVczn43/93mqQeO5DjMUMdeKa5OUvsQ0flsF1GU4ca6dS76+E2num0M
YSXYNhXLhWBcez3WPP28Ae0l6R1ihIAKiBX9mEd+pDrSEfCT/ctxCodaO9rVEwVhh9vi
OxNw==
MIME-Version: 1.0
X-Received: by 10.112.162.38 with SMTP id xx6mr45788484lbb.110.1436129631410;
Sun, 05 Jul 2015 13:53:51 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 13:53:51 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 13:53:51 -0700 (PDT)
In-Reply-To: <559994A4.5010401@openbitcoinprivacyproject.org>
References: <CABr1YTf72fdQmTDEHAWVKqvTCLSpJZyiiw4g3ifrY8x5RZ=shQ@mail.gmail.com>
<CABr1YTfwcOQuNyqO57=jdghTnqt56u6pBvK6+dWbED-4OMh+Ug@mail.gmail.com>
<CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
<CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com>
<559994A4.5010401@openbitcoinprivacyproject.org>
Date: Sun, 5 Jul 2015 13:53:51 -0700
Message-ID: <CABr1YTd5Tv5QPq3-W=1a4V2hTaOhg_0PBW5wdWD5G8jfkdKM=A@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Content-Type: multipart/alternative; boundary=089e01227baa881e2a051a26fca4
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Thoughts on Forks, Scalability,
and other Bitcoin inconveniences.
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: Sun, 05 Jul 2015 20:53:54 -0000
--089e01227baa881e2a051a26fca4
Content-Type: text/plain; charset=UTF-8
Perhaps I didn't write that so well if I gave that impression. Perhaps
taking a look at some of my work in this space would make you think
otherwise. (yes, I've implemented an entire SPV stack from scratch...look
it up.)
But all patronizing aside, your claim that "the reason an attacker can fool
SPV clients into accepting invalid blocks is because there exists no
mechanism via which honest nodes can prove the invalidity of blocks" is
exactly to the point...and building such a mechanism would address the
first of the two options I give: make it cheap to securely validate or take
trust into account.
- Eric Lombrozo
On Jul 5, 2015 1:34 PM, "Justus Ranvier" <
justus@openbitcoinprivacyproject.org> wrote:
> On 07/05/2015 01:50 PM, Eric Lombrozo wrote:
> > The only practical way for the network to function at present (and what
> has
> > essentially ended up happening, if often tacitly) is by introducing
> trust,
> > in validators, miners, relayers, explorer websites, online wallets,
> > etc...which in and of itself wouldn't be the end of the world were it not
> > for the fact that the raison d'etre of bitcoin is trustlessness - and the
> > security model is very much based on this idea. Because of this, there's
> > been a tendency to deny that bitcoin cannot presently scale without
> trust.
> > This is horrible because our entire security model has gone out the
> > window...and has been replaced with something that isn't specified at
> all!
>
> When I read this, I get the impression that you (and possibly many
> others) never actually understood the Bitcoin security model in the
> first place.
>
> Bitcoin is a digital cash system that prevents double spending without
> using a trusted third party.
>
> More specifically, successful double spending in Bitcoin requires an
> attacker to pay a proof of work cost that exceeds the cumulative proof
> of work paid by all non-attackers since the original spend.
>
> The security model holds for any user who has access to the complete
> blockchain, and currently does not hold for all users who do not. An
> attacker can double spend without paying the full PoW cost the security
> model requires if users do not have a full copy of the blockchain which
> which to verify the attacker's blocks.
>
> That's a problem, but it's not an unfixable problem.
>
> The reason an attacker can fool SPV clients into accepting invalid
> blocks is because there exists no mechanism via which honest nodes can
> prove the invalidity of blocks.
>
> Implement that mechanism, and the security of SPV clients will far more
> closely resemble the security of full nodes.
>
>
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus@openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e01227baa881e2a051a26fca4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Perhaps I didn't write that so well if I gave that impre=
ssion. Perhaps taking a look at some of my work in this space would make yo=
u think otherwise. (yes, I've implemented an entire SPV stack from scra=
tch...look it up.)</p>
<p dir=3D"ltr">But all patronizing aside, your claim that "the reason =
an attacker can fool SPV clients into accepting invalid blocks is because t=
here exists no mechanism via which honest nodes can prove the invalidity of=
blocks" is exactly to the point...and building such a mechanism would=
address the first of the two options I give: make it cheap to securely val=
idate or take trust into account.</p>
<p dir=3D"ltr">- Eric Lombrozo<br><br></p>
<div class=3D"gmail_quote">On Jul 5, 2015 1:34 PM, "Justus Ranvier&quo=
t; <<a href=3D"mailto:justus@openbitcoinprivacyproject.org">justus@openb=
itcoinprivacyproject.org</a>> wrote:<br type=3D"attribution"><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 07/05/2015 01:50 PM, Eric Lombrozo wrote:<br>
> The only practical way for the network to function at present (and wha=
t has<br>
> essentially ended up happening, if often tacitly) is by introducing tr=
ust,<br>
> in validators, miners, relayers, explorer websites, online wallets,<br=
>
> etc...which in and of itself wouldn't be the end of the world were=
it not<br>
> for the fact that the raison d'etre of bitcoin is trustlessness - =
and the<br>
> security model is very much based on this idea. Because of this, there=
's<br>
> been a tendency to deny that bitcoin cannot presently scale without tr=
ust.<br>
> This is horrible because our entire security model has gone out the<br=
>
> window...and has been replaced with something that isn't specified=
at all!<br>
<br>
When I read this, I get the impression that you (and possibly many<br>
others) never actually understood the Bitcoin security model in the<br>
first place.<br>
<br>
Bitcoin is a digital cash system that prevents double spending without<br>
using a trusted third party.<br>
<br>
More specifically, successful double spending in Bitcoin requires an<br>
attacker to pay a proof of work cost that exceeds the cumulative proof<br>
of work paid by all non-attackers since the original spend.<br>
<br>
The security model holds for any user who has access to the complete<br>
blockchain, and currently does not hold for all users who do not. An<br>
attacker can double spend without paying the full PoW cost the security<br>
model requires if users do not have a full copy of the blockchain which<br>
which to verify the attacker's blocks.<br>
<br>
That's a problem, but it's not an unfixable problem.<br>
<br>
The reason an attacker can fool SPV clients into accepting invalid<br>
blocks is because there exists no mechanism via which honest nodes can<br>
prove the invalidity of blocks.<br>
<br>
Implement that mechanism, and the security of SPV clients will far more<br>
closely resemble the security of full nodes.<br>
<br>
<br>
--<br>
Justus Ranvier<br>
Open Bitcoin Privacy Project<br>
<a href=3D"http://www.openbitcoinprivacyproject.org/" rel=3D"noreferrer" ta=
rget=3D"_blank">http://www.openbitcoinprivacyproject.org/</a><br>
<a href=3D"mailto:justus@openbitcoinprivacyproject.org">justus@openbitcoinp=
rivacyproject.org</a><br>
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>
--089e01227baa881e2a051a26fca4--
|
