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
|
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 43D1E8D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 15:11:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 005C611C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 15:11:01 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id f126so226040682wma.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 08:11:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=2XNJM5Aq8Lfsh61PJf+rc9PiuljVqNDyEfbJzKgr3II=;
b=QjJmxLrZdRCOM7eTk0MCKpG5bD922syKSJ9KpKVQulGUQQXUEJKaftE4mbCaqSMrSl
ZAz99vgpaFN0ZTcKO4h2SaOEjU6TMJMdVKDgrS28dDL2KUENBdLxH6mOn+1f2tcBv0Qo
4VUGIrNkgQjYQoE8ONqJz7QaqSD2y5HkqKFWbFY4JfuvjrbPhzBNs8LfQ/OlwBno7m6c
fATVvFl4npLLTYVHbiGFsqg9MitevhtWkMrlLACzjrmhEffxMG9rz4GLjdA/+C4xovZ/
LL45J/xvrZm2NCC+dC4o4qdpMRs1BjT3FkkFcrzJ0aTX+MFxc8E4aeDcLOEDg0Bx9Mzm
p+qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=2XNJM5Aq8Lfsh61PJf+rc9PiuljVqNDyEfbJzKgr3II=;
b=mNassocZgtJNfc/ou4pUozA6BifrYrFm3ClhCmhDK84yrW9y4nUd1ZJK9/SEvmxLN3
j6NyyX0LHrHXLd1bSvI18ARpAts3nXM+nTWsc3FLuoQ1JOf4WJqKGIuV1bmPLBjRt20Q
TRrJYzSZ1g4tReDd2LIVlapgZUJ6eubhR+JnlHU3Kl5JhKeElChWu5e5Mrq4pwavpKf1
0voP4HYqnlOx2w0gHCbxsKFOtNKBZPnvlyeknEAN9+7hQ45RCUjsb0w8qttYf9QLURMy
DGtV5mqtEEGTtJ9XhJuWMxqPxBI5Kt+owncN/G5ifelOvcg5JWMtTC937G74F2edMF2v
ud5A==
X-Gm-Message-State: ALyK8tLcBFG+61HeYhvY5Jfj9owmBlgbowYEiNAyz/vMtyXSgNppv0hmW7DiBPxC/2JB7Q==
X-Received: by 10.28.181.146 with SMTP id e140mr14642309wmf.38.1467299460443;
Thu, 30 Jun 2016 08:11:00 -0700 (PDT)
Received: from [197.161.188.155] ([197.161.188.155])
by smtp.gmail.com with ESMTPSA id
zb9sm3528934wjc.34.2016.06.30.08.10.59
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 30 Jun 2016 08:10:59 -0700 (PDT)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
Date: Thu, 30 Jun 2016 17:10:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Pieter Wuille <pieter.wuille@gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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 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: Thu, 30 Jun 2016 15:11:05 -0000
Pieter, these are in my opinion very reasonable positions. I've made some ob=
servations inline.
> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote=
:
>=20
> 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 t=
o privacy and the security of the network.
>=20
> I think this is a reasonable concern.
>=20
> 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 connec=
t to.
I explicitly exclude client-server behavior as I believe the proper resoluti=
on is to isolate clients from the P2P protocol. Libbitcoin does this already=
.
> Perhaps you deplore that fact, but I believe it is inevitable that differe=
nt pieces of the network will make different choices here. You can't prevent=
people from create connections along preexisting trust lines. That does not=
mean that the network as a whole relies on first establishing trust everywh=
ere.
Of course, the network operates just fine without universal trust. My concer=
n is not that it is required, but that it may grow significantly and will ha=
ve a tendency to gravitate towards more effective registration mechanisms fo=
r what is a "good" peer. Even an informal but pervasive web of trust may mak=
e it difficult for untrusted parties to connect.
> And I do think there are advantages.
>=20
> BIP 151 on its own gives you opportunistic encryption. You're very right t=
o point out that this does not give you protection from active attackers, an=
d that active attacking is relatively easy through sybil attacks. I still pr=
efer my attacker to actually do that over just listening in on my connection=
.
We agree, and the ease of this attack must be acknowledged. And given that t=
he protection is weak it is not unreasonable to consider the potential downs=
ide of creeping node identity.
> And yes, we should also work on improving the privacy nodes and wallets ha=
ve orthogonal to encryption, but nothing will make everything perfectly priv=
ate.
I agree, and I doubt this proposal will have much impact on an advanced pers=
istent threat, or even lesser threats. People should understand that there i=
s both a risk and a limited benefit to this proposal.
> BIP 151 plus a simple optional pre-shared-secret authentication extension c=
an improve upon pure IP-based authentication, as well as simplify things lik=
e SSL tunnels, and onion addresses purely used as identity. This will still r=
equire explicit configuration, but not more than now.
I agree - I consider tunneling the legitimate use case for this proposal. Ye=
t when nodes become closely coupled they are not fully independent. I have a=
concern with these practices being promoted for general use while at the sa=
me time being strongly implemented.
> BIP 151 plus a non-leaking public key authentication scheme (where peers c=
an query "are you the peer with pubkey X?" but don't learn anything if the a=
nswer is no) with keys specific to the IP addresses can give a TOFU-like sec=
urity. Nodes already remember IP addresses they've succesfully interacted wi=
th in the past, and ban IP addresses that misbehave. Being able to tell whet=
her a node you connect to is the same as one you've connected to before is a=
natural extension of this,
With this I disagree. There is no way to know that a node is one you have co=
nnected to previously unless that node wants you to know (apart from relying=
on the IP address). This is of no value in detecting misbehaving nodes that=
do not want to be detected. Ones that don't care (eg broken nodes) can be s=
ufficiently managed by IP address.
> and does not require establishing any real-world identity beyond what we'r=
e already implicitly relying on.
>=20
> Perhaps these use cases and their security assumptions should be spelled o=
ut more clearly in the BIP.
Absolutely.
> If there is a misunderstanding, it should be clearly stated that BIP 151 i=
s only a building block for further improvements
>=20
>> Secondarily I am concerned about users operating under a false assumption=
about the strength of privacy.
>=20
> This is a widespread problem, but it exists far outside the scope of this p=
roposal. The privacy properties of Bitcoin are often
> misrepresented and even used as advertizements. The solution is education,=
not avoiding improvements because they may be misunderstood.
Yes, let's not make it worse. This is a secondary concern. I remain primaril=
y concerned about growth of node identity in a vain attempt to make transact=
ion submission private in the P2P protocol (and to patch the other client-se=
rver features, specifically Bloom filters). As you imply, we cannot stop peo=
ple from turning Bitcoin into a private network - but let's not facilitate i=
t either.
>> The complexity of the proposed construction is comparable to that of Bitc=
oin itself.
>=20
> I really think this is an exaggeration. It's a diffie-hellman handshake an=
d a stream cipher (both very common constructions), that apply to individual=
connections. There are no consensus risks nor a
> requirement for coordinated change through the network. The
> cryptographic code can be directly reused from a well-known project
> (OpenSSH), and is very small in size.
I believe you have misinterpreted my comments on distributed anonymous crede=
ntials (and the like) as commentary on the construction of BIP151 (and a sub=
sequent auth proposal). As such your observation that it is exaggerated woul=
d make sense, but it is not what I intended. Encryption and auth are straigh=
tforward. Preventing bad nodes from participating in an anonymous distribute=
d system is not.
e=
|
