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
|
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 8AAB3483
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 23:33:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74D4216C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 23:33:56 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id f126so159084880wma.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 16:33:56 -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=PH+SO31nWDCCBuAwU0ge+quU82tmN8lluhy+WdxUzcU=;
b=pS08vM7YyEFnKEyQkhBMF8fDFyMHBCAxyX08w+86e5nhvspIonSDAbMsybYJbXkTQw
59rlQaWUJtkSwjN9GEHk3xq6s7KwWCWkzpJcKkbfzS3kHTpHuYg+mGKPgk6osYSB/+bm
KR97yUYIAQfy91W3Vst5EYOMRWnPWWm7olVAPqio8lgSojlslRZ7cPZSf/QIlzax1per
QcxrRO40IxVtpUY0u6vbT2XfUL2MIrn+w0wasOiUXIWqX5V6x475SnZLFeVp5NyGucM3
9ANYafAOgYdNXiVa48apeTtCKfcWpUa3PY29rEg0V4+hDDsa1YcCgPcTq6aaC7IbrFsk
Nbew==
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=PH+SO31nWDCCBuAwU0ge+quU82tmN8lluhy+WdxUzcU=;
b=B19kaXcdnGit8IXG9IrBsG0PmvlQa+Rcj/XpI6ibrYApmqXwsl0iC3wT6nhH7HK6t/
FD7zGtGuAgbCR9YgC+Y8y+/A7QJCGep1ycmJBPgFa8R1JAD0s1OkSP5C5ukLDZUhdfhg
IXtXCduc+vFVnWiRcDSqTvzYo0Drmnfu1LCy0B5PAyp+2Wab6jUHAeUgZrk44pyAVFO6
3xKW3QeCFAYf0W7u2/fxbk0mWxOfgmFW+k8wmv67SeKt3CkX7FoOAkEYna8bPansMPaa
nrSBG66JbpiChbhiYove/r+TNOWLH20WZohLWLpvKzvgnGPLoaGwLUKh2uHei+0ulgnh
+CcA==
X-Gm-Message-State: ALyK8tKRM1be6axPniPdc9pCdBytNCboeBVGegNdMr3Wm5kuMvXhDVpbU0sVwYtdle8UdA==
X-Received: by 10.28.140.202 with SMTP id o193mr19538026wmd.55.1467156835144;
Tue, 28 Jun 2016 16:33:55 -0700 (PDT)
Received: from [10.114.7.71] ([41.33.219.246])
by smtp.gmail.com with ESMTPSA id a4sm664440wjq.40.2016.06.28.16.33.54
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 28 Jun 2016 16:33:54 -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: <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
Date: Wed, 29 Jun 2016 01:33:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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
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: Tue, 28 Jun 2016 23:33:57 -0000
On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>> I understand the use, when coupled with a yet-to-be-devised identity syst=
em, with Bloom filter features. Yet these features
>=20
> This is a bit of a strawman, you've selected a single narrow usecase which=
isn't proposed by the BIP and then argue it is worthless. I agree that exam=
ple doesn't have much value (and I believe that
> eventually the BIP37 bloom filters should be removed from the protocol).
I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as i=
ts justifying scenario.
> Without something like BIP151 network participants cannot have privacy for=
the transactions they originate within the protocol against network observe=
rs.
And they won't get it with BIP151 either. Being a peer is easier than observ=
ing the network. If one can observe the encrypted traffic one can certainly u=
se a timing attack to determine what the node has sent.
> Even if, through some extraordinary effort, their own first hop is encrypt=
ed, unencrypted later hops would rapidly
> expose significant information about transaction origins in the network.
As will remain the case until all connections are encrypted and authenticate=
d, and all participants are known to be good guys. Starting to sound like PK=
I?
> Without something like BIP151 authenticated links are not possible, so
> manually curated links (addnode/connect) cannot be counted on to provide p=
rotection against partitioning sybils.
If we trust the manual links we don't need/want the other links. In fact ret=
aining the other links enables the attack you described above. Of course the=
re is no need to worry about Sybil attacks when all of your peers are authen=
ticated. But again, let us not ignore the problems of requiring all peers on=
the network be authenticated.
> Along the way BIP151 appears that it will actually make the protocol faste=
r.
>=20
>> Given that the BIP relies on identity
>=20
> This is untrue. The proposal is an ephemerally keyed opportunistic
> encryption system. The privacy against a network observer does not depend o=
n authentication, much less "identity". And when used with authentication a=
t all it makes interception strongly detectable after the fact.
Maybe I was insufficiently explicit. By "relies on identity" I meant that th=
e BIP is not effective without it. I did not mean to imply that the BIP itse=
lf implements an identity scheme. I thought this was clear from the context.=
>> The BIP does not [...] contemplate the significant problems associated wi=
th key distribution in any identity system
>=20
> Because it does not propose any "identity system" or authorization (also, I=
object to your apparent characterization of authentication as as an 'identi=
ty system'-- do you also call Bitcoin addresses an identity system?).
Please read more carefully what I wrote. I did not characterize authenticati=
on as an identity system. I proposed that key distribution has significant p=
roblems, and used identity systems as an example of systems with such proble=
ms. I could just have easily written "authentication systems", (and probably=
should have).
> That said, manually maintaining adds nodes to your own and somewhat truste=
d nodes is a recommend best practice for miners and other high value systems=
which is rendered much less effective due to a lack of
> authentication, there is no significant key distribution problem in that c=
ase
This is the only legitimate scenario that I am aware of. Doing this by IP ad=
dress (as we do) is weak if there is no VPN.
Yet this scenario is very different than general authentication. This scenar=
io is a set of nodes that is essentially a single logical node from the pers=
pective of the Bitcoin security model. One entity controls the validation ru=
les, or is collaborating with another entity to do so.
My concern is that a general authentication requirement expands this single l=
ogical node and gives control over if to the entity that controls key distri=
bution - the hard problem that hasn't been addressed.
If there is no such entity restricting access to the network (which hopefull=
y we can assume) then there is no reason to expect any effective improvement=
, since nodes will necessarily have to connect with anonymous peers. Anyone w=
ith a node and the ability to monitor traffic should remain very effective.
> and I expect the future auth BIP (Jonas had one before, but it was put asi=
de for now to first focus on the link layer encryption)
> to address that case quite well.
Defining an auth implementation is not a hard problem, nor is it the concern=
I have raised.
e=
|
