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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5108F97
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 01:57:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu
[18.9.25.12])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D060D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 01:57:12 +0000 (UTC)
X-AuditID: 1209190c-f79c96d00000038e-fe-563c08f7b6db
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])
(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP
id EC.EA.00910.7F80C365; Thu, 5 Nov 2015 20:57:11 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA61vA25001871
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 20:57:11 -0500
Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com
[209.85.160.182]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA61v9tq014423
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 20:57:10 -0500
Received: by ykek133 with SMTP id k133so165909280yke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Nov 2015 17:57:08 -0800 (PST)
X-Received: by 10.129.132.86 with SMTP id u83mr1037300ywf.111.1446775028917;
Thu, 05 Nov 2015 17:57:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.156.69 with HTTP; Thu, 5 Nov 2015 17:56:49 -0800 (PST)
In-Reply-To: <563BE746.5030406@voskuil.org>
References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
<563BE746.5030406@voskuil.org>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 5 Nov 2015 20:56:49 -0500
X-Gmail-Original-Message-ID: <CAD5xwhj3Ys+kFaoFAqM4e_mec--02pij72ze6NoJ6+AaQdL0tA@mail.gmail.com>
Message-ID: <CAD5xwhj3Ys+kFaoFAqM4e_mec--02pij72ze6NoJ6+AaQdL0tA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a114f25fcab307b0523d58f9c
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6novudwybMYMpNMYum17YOjB6/f0xm
DGCM4rJJSc3JLEst0rdL4MrYtuQte8Flw4p7E26yNjDO0Opi5OSQEDCRWHqzlRXCFpO4cG89
WxcjF4eQwGImifkTO6CcO4wSzXNnMUM4H5gkLj/qZYFwJjFKtD+ewQzRXyLxduZ6dhCbV0BQ
4uTMJ0BFHEBFXhKfvxqChDkFtCX2rrrGBmILCRRKzPi0hR2khE1ATuLDL1MQk0VARWLnUW6I
gYkSn37MZoIYGCDxe+EcsEOFBXwlbt1cwApSLiKgLNF8oRokzCyQJLHg6HdmCNtL4smaGSwT
GIVnITlnFpLULKBuZgF1ifXzhCDCahK3t11lh7C1JZYtfM28gJF1FaNsSm6Vbm5iZk5xarJu
cXJiXl5qka6hXm5miV5qSukmRlAUcEry7GB8c1DpEKMAB6MSD6/BcuswIdbEsuLK3EOMkhxM
SqK8Lr+BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR45ZhtwoR4UxIrq1KL8mFS0hwsSuK8m37w
hQgJpCeWpGanphakFsFkZTg4lCR4o9iBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGZ4DU8BYXJOYW
Z6ZD5E8xWnKsm3FtLRPHlt8gctvUe2uZhFjy8vNSpcR5i0AaBEAaMkrz4GaCktrF0AXbXjGK
A70ozNsLUsUDTIhwU18BLWQCWsjUagGysCQRISXVwLiobFuKAIvTEsWq9IIzSmflqi5aJ8WU
/NsYMWGzy7LpxYZt3LILBG7UNHcavpv77vUKDZv1FQ+39sYHK12LuvO47PvE457P5lc+2PmI
4+P9z3Prkjd67Nsk5qH5d6LyV0OxlSx/j170jNyZ6seWYPapd77bKqdHtk7Xbxzaz6GrxfEj
ctO+9W1KLMUZiYZazEXFiQAxr+0bRQMAAA==
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD 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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
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: Fri, 06 Nov 2015 01:57:13 -0000
--001a114f25fcab307b0523d58f9c
Content-Type: text/plain; charset=UTF-8
I'd also like to see some more formal analysis of the notion that "$10 in
the hand of 10 people is more than $50 in the hand of two, or $100 in the
hand of one". I think this encapsulates the security assumption on why we
want decentralization at all.
This is a very critical property bitcoin exploits for being able to
transact large amounts, among other things. (Closely related is the notion
that defecting will destroy all the value...)
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
> > ...
> > Validators: Economically dependent full nodes are an important part of
> > Bitcoin's security model because they assure Bitcoin security by
> > enforcing consensus rules. While full nodes do not have orphan
> > risk, we also dont want maliciously crafted blocks with pathological
> > validation cost to erode security by knocking reasonable spec full
> > nodes off the network on CPU (or bandwidth grounds).
> > ...
> > Validators vs Miner decentralisation balance:
> >
> > There is a tradeoff where we can tolerate weak miner decentralisation
> > if we can rely on good validator decentralisation or vice versa. But
> > both being weak is risky. Currently given mining centralisation
> > itself is weak, that makes validator decentralisation a critical
> > remaining defence - ie security depends more on validator
> > decentralisation than it would if mining decentralisation was in a
> > better shape.
>
> This side of the security model seems underappreciated, if not poorly
> understood. Weakening is not just occurring because of the proliferation
> of non-validating wallet software and centralized (web) wallets, but
> also centralized Bitcoin APIs.
>
> Over time developers tend to settle on a couple of API providers for a
> given problem. Bing and Google for search and mapping, for example. All
> applications and users of them, depending on an API service, reduce to a
> single validator. Imagine most Bitcoin applications built on the
> equivalent of Bing and Google.
>
> e
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a114f25fcab307b0523d58f9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I'd also like to s=
ee some more formal analysis of the notion that "$10 in the hand of 10=
people is more than $50 in the hand of two, or $100 in the hand of one&quo=
t;. I think this encapsulates the security assumption on why we want decent=
ralization at all.<br><br></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This is=
a very critical property bitcoin exploits for being able to transact large=
amounts, among other things. (Closely related is the notion that defecting=
will destroy all the value...)<br><br><br></div></div><div class=3D"gmail_=
extra"><br clear=3D"all"><div><br clear=3D"all"><div><div class=3D"gmail_si=
gnature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin"=
target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRub=
in" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil=
via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/05/2015 03:=
03 PM, Adam Back via bitcoin-dev wrote:<br>
> ...<br>
<span class=3D"">> Validators: Economically dependent full nodes are an =
important part of<br>
> Bitcoin's security model because they assure Bitcoin security by<b=
r>
> enforcing consensus rules.=C2=A0 While full nodes do not have orphan<b=
r>
> risk, we also dont want maliciously crafted blocks with pathological<b=
r>
> validation cost to erode security by knocking reasonable spec full<br>
> nodes off the network on CPU (or bandwidth grounds).<br>
</span>> ...<br>
<span class=3D"">> Validators vs Miner decentralisation balance:<br>
><br>
> There is a tradeoff where we can tolerate weak miner decentralisation<=
br>
> if we can rely on good validator decentralisation or vice versa.=C2=A0=
But<br>
> both being weak is risky.=C2=A0 Currently given mining centralisation<=
br>
> itself is weak, that makes validator decentralisation a critical<br>
> remaining defence - ie security depends more on validator<br>
> decentralisation than it would if mining decentralisation was in a<br>
> better shape.<br>
<br>
</span>This side of the security model seems underappreciated, if not poorl=
y<br>
understood. Weakening is not just occurring because of the proliferation<br=
>
of non-validating wallet software and centralized (web) wallets, but<br>
also centralized Bitcoin APIs.<br>
<br>
Over time developers tend to settle on a couple of API providers for a<br>
given problem. Bing and Google for search and mapping, for example. All<br>
applications and users of them, depending on an API service, reduce to a<br=
>
single validator. Imagine most Bitcoin applications built on the<br>
equivalent of Bing and Google.<br>
<br>
e<br>
<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><br></div>
--001a114f25fcab307b0523d58f9c--
|
