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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 69D5C6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 14:29:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C274820A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 14:29:55 +0000 (UTC)
Received: by mail-ua0-f172.google.com with SMTP id l94so91568574ual.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Aug 2016 07:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=1RcPsDlNUCpav+Oh9jT2KsHEBzUlON1Xrn2TuhCO2og=;
b=dlnTOM8Zd5sTopprPVtl4Dm/JD2Fq7edurG/MmT4Y2wDYvPEMyn+8VZuJAC9B/Ve+a
f/xBDtpoWF+t7Ad2cmYNcYgwL8wKmqURLRSK1jymEuti95S9xNKgsAPZPLi5hWufRcaS
1YiHTgtHfmaQgSnixsId3Ei604zUsifVvY5bfsz6baWshcWeJSRf1B2CxCypJw81f9RJ
mJtLOaCwdhiL2SHoir3i5iTBn7KIK6g/6kT9VtvD1gEtSzFfWao6dUgH3coGQG3lNX2X
xrtUsg2L/f25VfANmNva3PP+kBwfTdJotY75raaAvBu3LpFixuV/CWEGdpFmj6dk2zgx
bepQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=1RcPsDlNUCpav+Oh9jT2KsHEBzUlON1Xrn2TuhCO2og=;
b=IUtpcQUrOnb0+2mtdWHft78o0yDm9SzxzJE21wUPTCFwuethJwuQVnYH/Bfy8XNFYS
z8pj7cRgiD55qTcT2RowKdsPzVtUYNLnejg1ns9q1K2tJKXcrQl26SZo2yfinrwN/bql
ll0Vymi2U2tgZVYZBXxypRqUoC4ArrKjbVoEeBzBh73ebcwh9AZ4UTTTZ5uakSl6NMyP
lsL7tDyIdnqClgZbwuJ0Jz+cDObPEkb96QZipmKRhUXczLWIkQ9YoknUbHzUV7SCKID7
jo3T4wJyA1hZ5NxlToDtPSFjV1HMnAWXesfH4I16JZX8ff+HA9VXwqnDlHPKt6A+CLu/
sH0w==
X-Gm-Message-State: AE9vXwM7EqN3evAum+4RPcn1kBoCV+59AWvLs6V7/Cwvhm44uQG7doVq4SmNYtKL3N8B5TuQA91Z+Qn1TL8Ehw==
X-Received: by 10.31.158.200 with SMTP id h191mr5831868vke.127.1472653794698;
Wed, 31 Aug 2016 07:29:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.51.77 with HTTP; Wed, 31 Aug 2016 07:29:53 -0700 (PDT)
In-Reply-To: <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
<CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
<CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
<CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
<0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 31 Aug 2016 16:29:53 +0200
Message-ID: <CAPg+sBhZaSkRc9yDKHYPjq3oD_bXZ1GsBgzgqOV_Dcd-LZY3BA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 31 Aug 2016 14:29:56 -0000
Hello Eric,
I felt like I still owed you a response to the points below.
On Thu, Jun 30, 2016 at 5:10 PM, Eric Voskuil <eric@voskuil.org> wrote:
> Pieter, these are in my opinion very reasonable positions. I've made some=
observations inline.
>
>> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille@gmail.com> wro=
te:
>>
>> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> The proliferation of node identity is my primary concern - this relates=
to privacy and the security of the network.
>>
>> I think this is a reasonable concern.
>>
>> However, node identity is already being used widely, and in a very
>> inadvisable way:
>> * Since forever there have been lists of 'good nodes' to pass in
>> addnode=3D configuration options.
>> * Various people run multiple nodes in different geographic locations,
>> peering with each other.
>> * Various pieces of infrastructure exist that relies on connecting to
>> well-behaving nodes (miner relay networks, large players peering
>> directly with each other, ...)
>
> Yes, libbitcoin also provides these options on an IP basis.
>
>> * Several lightweight clients support configuring a trusted host to conn=
ect to.
>
> I explicitly exclude client-server behavior as I believe the proper resol=
ution is to isolate clients from the P2P protocol. Libbitcoin does this alr=
eady.
I think that's a false dichotomy. There is no reason why the P2P
network consists of purely servers (full nodes) and clients
(lightweight nodes). Where does a client fit that is SPV at startup,
but upgrades in the background to a full node? It seems strange that
such a client would use a 'client protocol' for initial connections,
but the P2P protocol for syncing with history, when both come from the
same peers, and transmit the same kind of information.
What would make sense IMHO is a protocol split between the different
kinds of transmission:
1) Historical block download
2) Block synchronization at the tip
3) Transaction relay
...
(1) prefers high bandwidth, has no connectivity concerns, and does not
care about latency and has no privacy concerns. (2) needs
partition-resistance, low latency and has also no privacy concerns.
(3) needs moderate latency, reliability of propagation and privacy.
If there were to be separate protocols for these, I would argue that
(3) should use opportunistic encryption always to increase transaction
source privacy, and (2) and (3) need authentication when one of the
peers is not fully validating.
BIP 150/151 give the tools to construct these.
>> Perhaps you deplore that fact, but I believe it is inevitable that diffe=
rent pieces of the network will make different choices here. You can't prev=
ent people from create connections along preexisting trust lines. That does=
not mean that the network as a whole relies on first establishing trust ev=
erywhere.
>
> Of course, the network operates just fine without universal trust. My con=
cern is not that it is required, but that it may grow significantly and wil=
l have a tendency to gravitate towards more effective registration mechanis=
ms for what is a "good" peer. Even an informal but pervasive web of trust m=
ay make it difficult for untrusted parties to connect.
Maybe, but I'm very unconvinced that that will happen more than how
today IP and DNS-based "authentication" is used already (in very
inadvisable ways).
>> And I do think there are advantages.
>>
>> BIP 151 on its own gives you opportunistic encryption. You're very right=
to point out that this does not give you protection from active attackers,=
and that active attacking is relatively easy through sybil attacks. I stil=
l prefer my attacker to actually do that over just listening in on my conne=
ction.
> I agree, and I doubt this proposal will have much impact on an advanced p=
ersistent threat, or even lesser threats. People should understand that the=
re is both a risk and a limited benefit to this proposal.
I believe the risk is only in misunderstanding what it is good for,
and there significant benefits to a network that encrypts connections
by default, as it excludes purely passive attackers.
> I believe you have misinterpreted my comments on distributed anonymous cr=
edentials (and the like) as commentary on the construction of BIP151 (and a=
subsequent auth proposal). As such your observation that it is exaggerated=
would make sense, but it is not what I intended. Encryption and auth are s=
traightforward. Preventing bad nodes from participating in an anonymous dis=
tributed system is not.
Preventing bad nodes from participating is a very hard problem, if not
impossible. That doesn't mean we can't improve the current situation:
people are relying on node identity already, and doing so in ways that
have unclear attack vectors (IP spoofing, DNS poisoning, BGP routing
attacks). Adding optional and non-discoverable cryptographic
identities can improve this.
--=20
Pieter
|
