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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 148BE1BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Nov 2015 00:46:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
[209.85.220.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3858CFB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 Nov 2015 00:46:56 +0000 (UTC)
Received: by padhx2 with SMTP id hx2so129776378pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Nov 2015 16:46:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil_org.20150623.gappssmtp.com; s=20150623;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:references:in-reply-to:content-type;
bh=lG55eStLfXknhqCgZNhnCQ/Nh4qLCwODVM970cNpXeI=;
b=A3GevWXeE4+NjoVeb+apep/NVG2eCUC6hMEaklxR5VseznbeWeftlL5igeHxesaFAz
cjRBoZhQFFzLYxR4L8aA4YvVL4Vwc2VDlZKRefD+8Hgb3mOfLJidEDn2/Fj7/poDH4Xq
NsNhaBTscLMAVr1syYH7dGIC/L7Kvq+sVCoT8grlOHJYUz1a5PauiLFZ3zkReUMskOqw
/fl+6vHZp9MWUasHmdpHiqSR57u8Oytvh/y24UnkmHfhD00PwLdFoUtkNYqMafbV16kG
CNYRExoxMTtCdtcjG4hftMrIA6GZGfdFE5sdSe5wwtNq4H/0B1yTYcuA62KoOb7FQj+N
tT4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type;
bh=lG55eStLfXknhqCgZNhnCQ/Nh4qLCwODVM970cNpXeI=;
b=APsl9TwP5AFWBeAmrzGFULnNOkAOF3+RUHXYhB3TmwHSOeOPL4wDEOHG8J0JqUPlbS
+Zo7rr79/hjFvQafeSi9Mbgif40ZvCWz5I5l9GYHhbHkwRT9hp9WWyUP0/0gBXdaqWaD
Vbd/c5gVIv3PXAk4ymLI6vv9eBLjB0foAKCDUdA8Jy+1zvUvbFKMNuFtYZN1ZY01gcYu
UrCdghiBRQldi8Icyt1wLVg9uaLop45uPeDUsltsDm3p+vtU8C6hQReYmH9cC+QEe/m7
WS4GtCF2eandeUpYG0Jt0NroW2KM5vK6wNiz5UeEjL9B1L6UPQmx0/PfnpOII7XEzOWi
fpRg==
X-Gm-Message-State: ALoCoQkGtwuvKYVG99jhawpthmpB4FfcvYjfOeqyLITrenBxjhHwS2V7PrIwrPnzS6bpMBqi48Cq
X-Received: by 10.66.102.1 with SMTP id fk1mr21367519pab.111.1446857215900;
Fri, 06 Nov 2015 16:46:55 -0800 (PST)
Received: from [10.0.1.18] (c-73-225-134-208.hsd1.wa.comcast.net.
[73.225.134.208]) by smtp.googlemail.com with ESMTPSA id
sx1sm2240888pbc.36.2015.11.06.16.46.54
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 06 Nov 2015 16:46:55 -0800 (PST)
Message-ID: <563D4980.9080604@voskuil.org>
Date: Fri, 06 Nov 2015 16:44:48 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Chris Priest <cp368202@ohiou.edu>, Adam Back <adam@cypherspace.org>
References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com> <563BE746.5030406@voskuil.org> <CAAcC9yv6JwSY-LhWaFc5cF6CkTwTfLLtqFfemwjJ7hKnfzXuLQ@mail.gmail.com> <CALqxMTGnusroDgjt0a7HqfPpS=1n7WNu1uz6bOPG2vQAbCNQ1g@mail.gmail.com>
<CAAcC9yvq51pj_yH_SsbqGg08sgwNZJ-h+YnY4ekgDUNYLBSRxQ@mail.gmail.com>
In-Reply-To: <CAAcC9yvq51pj_yH_SsbqGg08sgwNZJ-h+YnY4ekgDUNYLBSRxQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="amoFwicVJHo64U4D8Abt1U0GuUdKCL2Ij"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW,T_TVD_FUZZY_SECURITIES autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 07 Nov 2015 01:38:05 +0000
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: Sat, 07 Nov 2015 00:46:57 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--amoFwicVJHo64U4D8Abt1U0GuUdKCL2Ij
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 11/06/2015 03:41 PM, Chris Priest wrote:
>> The bigger point however, which Erik explained, was: widespread use of=
>> APIs as a sole means of interfacing with the blockchain also
>> contributes to reducing network security for everyone, because it
>> erodes the consensus rule validation security described under
>> "Validators" in the OP.
>=20
> I completely disagree with this. You are implying that there is some
> sort of ideal ratio of full nodes to 'client only' nodes that the
> network must maintain. You seem to be implying that if that ideal
> ratio is to somehow be disrupted, then security suffers. My question
> to you is what is that ideal ratio and what methodology did you use to
> come up with it?
Nobody has advocated a golden ratio.
> The way I see it, the security of the system is independent on ratio
> between full nodes and lightweight nodes.
>=20
> In other words, if there are 100,000 lightweight wallets to 100 full
> nodes, then you have the same security profile as one with 100,000
> full nodes to 100 lightweight wallets.
This is a false dichotomy. Both scenarios are poor for security, as
nobody with a wallet is validating. It's entirely possible, even
probable, that one person controls all of the nodes.
> I think most 'big blockers' think the same way I do, hence the rub
> between the two camps.
>=20
> Small block people need to make a better case as to how exactly full
> node ratio relates to network security (especially the 'for everyone'
> part), because the link is not clear to me at all. Small block people
> seem to take this simple fact as self evident, but I just don't see
> it.
Fewer people independently validating their own transactions means trust
is placed in fewer people. The degenerate case of one validator and
everyone trusting it is dispositive, and equates roughly to the Federal
Reserve.
> On 11/6/15, Adam Back <adam@cypherspace.org> wrote:
>> You're right that it is better that there be more APIs than fewer,
>> that is less of a single point of failure. It also depends what you
>> mean by APIs: using an API to have a second cross-check of information=
>> is quite different to building a wallet or business that only
>> interfaces with the blockchain via a 3rd party API. There are
>> different APIs also: some are additive eg they add a second signature
>> via multisig, but even those models while better can still be a mixed
>> story for security, if the user is not also checking their own
>> full-node or checking SPV to make the first signature.
>>
>> Power users and businesses using APIs instead of running a full-node,
>> or instead of doing SPV checks, should be clear about the API and what=
>> security they are delegating to a third party, and whether they have a=
>> reason to trust the governance and security competence of the third
>> party: in the simplest case it can reduce their and their users
>> security below SPV.
>>
>> The bigger point however, which Erik explained, was: widespread use of=
>> APIs as a sole means of interfacing with the blockchain also
>> contributes to reducing network security for everyone, because it
>> erodes the consensus rule validation security described under
>> "Validators" in the OP.
>>
>> Adam
>>
>>
>> On 6 November 2015 at 09:05, Chris Priest <cp368202@ohiou.edu> wrote:
>>> On 11/5/15, 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 pathologica=
l
>>>>> 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 decentralisati=
on
>>>>> if we can rely on good validator decentralisation or vice versa. B=
ut
>>>>> 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 poorl=
y
>>>> understood. Weakening is not just occurring because of the prolifera=
tion
>>>> 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
>>>>
>>>>
>>>
>>> I disagree. I think blockchain APIs are a good thing for
>>> decentralization. There aren't just 3 or 4 blockexplorer APIs out
>>> there, there are dozens. Each API returns essentially the same data,
>>> so they are all interchangeable. Take a look at this python package:
>>> https://github.com/priestc/moneywagon
>>
--amoFwicVJHo64U4D8Abt1U0GuUdKCL2Ij
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWPUmAAAoJEDzYwH8LXOFOVNQH/3BUNihlcjpebMCLs65Uabqa
4ARZTBTx0ZFcOK6pS2gGvr3P5NmWYff8Lvl8G/v+wUngovRSimhpyR+cox0PYF/Q
WbInIefbk/D5I64CH+8UAPnrxM/l5IIg92FbtbRblTh4j0MU6YmIqwsvOyIyPt0y
DHCISHQT/nZNZmtKQXNhpbdRcVOA2IRfLLIj3usisB3AYU4w6F+k7PJKsuxGAMsQ
OgJwFtl3qZC+w+oZeDURjii59ufiNn9FEDvEOdbSkSFoWrHdP+uB4Ps2yL2MnBIi
/qtMObtcxiebWuKRTY+IFh01cEpQg5uqK2cD/nOCByjHkRne0S3o+GANsRcAk5E=
=NeUW
-----END PGP SIGNATURE-----
--amoFwicVJHo64U4D8Abt1U0GuUdKCL2Ij--
|
