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
|
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 9D4A0955
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 17:39:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B77D92A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 17:39:50 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id r201so38424895wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 10:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:message-id:date
:references:in-reply-to:to;
bh=SKc3CJ2JEOEYqDrQiTjt/ntEXIWcOvZkxX6U8q574DE=;
b=rf99GWG2j2e1DqftPK7F2EXz8feZecwKB7jnQiZJxGuTqPLM3Bg972wkfuX8NUe5gB
XXdc+An+VnwHFC7Sn0eUqi2LXPuCo9XgyCgS517MJaNAk97+vjQKi8vt5eC8kmRKLyqY
xchMYCRxfs9tlmurYTyhRKrq4spIIxY3LDcZqLR4OXI0ixwgpgl2WUdhzEfkTSVono8a
XAUHhAeM4topDw3h/29mX/rzf7JXy1AaxjZ4mu56a8oN+aBNltYXXPCxxnQ8/ReNL2ki
9h6570v5zhueMgWL02Dnprwlc1Laa+uSVBaC8hHHyMk2towLCT3MHXvjEw0lHI0nf1ky
zMxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:message-id:date:references:in-reply-to:to;
bh=SKc3CJ2JEOEYqDrQiTjt/ntEXIWcOvZkxX6U8q574DE=;
b=Au2YJxee5EAxlXh0eabogwjFRMQ6G/BpXuRb2UJ5lhs+RHxTEuM1BBMhIWlxk43sEx
8eaqSvrhor1W0qqQvkIjwDpOvHaeOcZ4wjktIrlGhejqBQJSdfJ0keM52V/at6QG0dTw
fU7i1t94OmE8MHxm4l8Mvr89n/FVmuUYcSVitrmszZ2Hm077WOWB2rFCVF0NC4eSMm5u
4GJtvBrhx2w93cqmvwnv3frwETqaTkL8nh/zCgr9VDfoF6Z++/dNozCNSR9CnMdfWmok
0KLlTuMsm0PtUC/ivGIL07j8PmHghK7A8QibpTjKdb/AUnmbVtUOVPVgnY5wOwHBfRWG
fr5Q==
X-Gm-Message-State: ALyK8tLahD7KvadxiA0UuL/xcrekuWUFiV2vdJfaU9TQYyJn8cc2ILhu7GKx+Ww7hE2+eA==
X-Received: by 10.28.227.136 with SMTP id a130mr18016843wmh.3.1467135589152;
Tue, 28 Jun 2016 10:39:49 -0700 (PDT)
Received: from [10.114.7.71] ([41.33.219.254])
by smtp.gmail.com with ESMTPSA id o2sm3639835wjp.26.2016.06.28.10.39.47
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 28 Jun 2016 10:39:48 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Message-Id: <2E638F35-D212-43B7-A9AB-7D7C33CFF781@voskuil.org>
Date: Tue, 28 Jun 2016 19:39:41 +0200
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577269E7.6020008@jonasschnelli.ch>
In-Reply-To: <577269E7.6020008@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (13F69)
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 17:39:51 -0000
continued from previous post...
> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>=20
> Hi Eric
>=20
> Sorry for not directly addressing your points.
No problem. Thanks for the detailed replies.
> I try to be more precise in this follow up email:
>=20
>> I understand the use, when coupled with a yet-to-be-devised identity syst=
em, with Bloom filter features. Yet these features are client-server in natu=
re. Libbitcoin (for example) supports client-server features on an independe=
nt port (and implements a variant of CurveCP for encryption and identity). M=
y concern arises with application of identity to the P2P protocol (excluding=
Bloom filter features).
>=20
> I think the bloom filter SPV usecase is not "pure client-server". SPV
> clients could request from/broadcast to multiple "trusted nodes".
I have referred to the Bloom filters messages. These are clearly asymmetric i=
n nature. Despite being possible it is not a valid use case for a full node t=
o make BF requests to another node.
One client to multiple servers is still client-server for the sake of this d=
iscussion. The nature of the P2P protocol is synchronization of content betw=
een all nodes/peers. If the protocol is asymmetric the semantics, and theref=
ore use cases, are different.
FWIW posting a transaction to the network can be done using the P2P protocol=
, connecting for a short period of time. But this is also a client-server sc=
enario and is a hack when done (full disclosure, bx provides both P2P and cl=
ient-server commands for tx posting). Broadcasting is naturally the behavior=
of a full node.
> Trusted nodes could be nodes where the operators have shared identities/ke=
ys in advance over a different channel.
Yes, this is necessarily the case in order to prevent a MITM attack. This is=
the basis of my concern.
> Further private p2p extensions (lets say a p2p form of the estimatefee
> command) are something which needs to be discussed first and not
> something that is encouraged or outlined in BIP151.
Sure, but then let us not make assumptions about it in the context of this d=
iscussion. Libbitcoin provides fee estimation by monitoring broadcast penetr=
ation using a client-server protocol with an optional subscription mechanism=
.
>> It seems to me that the desire to secure against the weaknesses of BF is b=
eing casually generalized to the P2P network. That generalization may actual=
ly weaken the security of the P2P protocol. One might consider the proper re=
solution is to move the BF features to a client-server protocol.
>=20
> I don't see reasons why BIP151 could weaken the security of the P2P networ=
k. Can you point out some specific concerns?
TOFU cannot prevent MITM attacks (the goal of the encryption). Authenticatio=
n requires a secure (trusted) side channel by which to distribute public key=
s. This presents what I consider a significant problem. If widespread, contr=
ol over this distribution network would constitute control over who can use B=
itcoin.
The effort to prevent censorship could actually enable it. I don't think it w=
ould get that far. Someone would point this out in the process of vetting th=
e authentication BIP, and the result would be the scrapping of BIP151.
>> The BIP does not make a case for other scenarios, or contemplate the sign=
ificant problems associated with key distribution in any identity system. Gi=
ven that the BIP relies on identity, these considerations should be fully ve=
tted before heading down another blind alley.
>=20
> BIP151 does not rely on identities. BIP151 does not use persisted keys
> (only ephemeral keys).
BIP 151 is incomplete without authentication.
> The authentication/identity system needs to be described in a another BIP.=
> But correct, BIP151 without a form of authentication/identity management
> is vulnerable to all sorts of MITM attacks and that's why I think BIP151
> must be deployed together with an p2p authentication scheme.
Agree, but my problem is that I do not believe we can assume this is a solva=
ble problem.
> Scope creeping and the risks of overspecifying is the main reason to
> focus on the "pure encryption part" in BIP151.
Understood, yet this is the basis of my blind alley comment.
e
> Thanks
> ---
> </jonas>
|
