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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 61C7A8D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 14:08:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8D7FC140
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 14:08:12 +0000 (UTC)
Received: from mail-ig0-f176.google.com ([209.85.213.176]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0MEm44-1ZfoWX2ide-00G7YC for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Nov 2015 15:08:11 +0100
Received: by igvi2 with SMTP id i2so32782541igv.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Nov 2015 06:08:11 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.178.142 with SMTP id cy14mr370507igc.18.1446818891023;
Fri, 06 Nov 2015 06:08:11 -0800 (PST)
Received: by 10.50.180.132 with HTTP; Fri, 6 Nov 2015 06:08:10 -0800 (PST)
In-Reply-To: <CAAcC9yv6JwSY-LhWaFc5cF6CkTwTfLLtqFfemwjJ7hKnfzXuLQ@mail.gmail.com>
References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
<563BE746.5030406@voskuil.org>
<CAAcC9yv6JwSY-LhWaFc5cF6CkTwTfLLtqFfemwjJ7hKnfzXuLQ@mail.gmail.com>
Date: Fri, 6 Nov 2015 15:08:10 +0100
X-Gmail-Original-Message-ID: <CALqxMTGnusroDgjt0a7HqfPpS=1n7WNu1uz6bOPG2vQAbCNQ1g@mail.gmail.com>
Message-ID: <CALqxMTGnusroDgjt0a7HqfPpS=1n7WNu1uz6bOPG2vQAbCNQ1g@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Chris Priest <cp368202@ohiou.edu>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:BMRuSNV3DdMqgsQ3jBBILCbWxTYd+OmFmwidftWH4/bUPVc7qez
J7QIdeG5hLCEHZBlUWDs26uVOWU9vHNnkmF19FhCD6QILlvk9w0c+YxuevjT7v/vsqmlx/R
W59l7cYXJ/NCHtSaiNr5YNMdrOGs2lTA6XvqwIOdw1WXRF3n8D5iWzWNhDXudHEp1CBIGAi
KSwrf1OEGxJDq32/EY8Qw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:tvjAIWFP/W0=:GQBY2WRUcJuIRBNp25XUf7
HM5AfPfItFXJZqkyiy030sREI37N6mwMvNUlhowI5zysZ4bxsqz3lh5+8o1WESHO2Dd8LhpSO
I6DSQcG4tLNLF9JfHZd1KEbIi0/P93/Rm57SIozkiw4lweAp+LT7H7fCqBk/XmYA3gybr+ykW
IofciBICTmKTiOaetQrQ94sBEDUmnu1RPjBAx/159kLh6hGLl5gjpqxXEs+o4QeCqjyC2SQdx
pY149R2GK/EP0MwEPHZQHlv08kGKDVKuRlYUPGndW/HChWJGMF5jIM6/wQSXzUk4dIsLdj0R5
Y/UhpyN2anZwAQF6hutUVrUOrFx4IDs9GfTFEWJT0hZ7YHQyIIVGXTt1SHZORE1bd8rmwXIRC
VR53IkDusR/yPTM2NSvWufU69yAA0att5q41RyIAfLCZvcC2gWhMMSATHdzM1CtvkeY2mPiqS
BCskXTFFw6PDSuw8gR/QiYbmHxN1hfitaCQElP5WTuBrHvGi5dYdBr0mH7FzgUaBoGusjbx6O
UQHpD6Zv5mp2haYgFKEDygpEUo15/1o5rSAOOFkiRcNrFFsCKrrQaa+4yl3IlKMmHTu7YcOaT
s3MFgDGSxo4bIQtlAdV5PGFYyMIrpNj6D8AEpiuzHhgL8gj+41OraVQXiIg7HNFWw9mMt32s6
+dXugWEYY/212894wu3+5WST/0FnvO9IlA8ttazjivOMBwSdB4fEv3XsJ8hlM5mTXYoriWp6R
WkipGUK+fZ8EUide
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
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 14:08:13 -0000
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 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
>>
>>
>
> 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
|
