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
|
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 D6E0CA73
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 23:34:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC6F81F8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 23:34:36 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id v199so158750555wmv.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 16:34:36 -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=oyoynKeIIprCD1jlo7eR+tDhfz6nYpFFtHJPAeoquj4=;
b=uI4PG0+OQB9pIMobadJuTL4b7/wIaZUSQc/LwC0B36G/KvPdr8cGw02Z2zqPrfLlmH
oP+f6Q8KpJ/cccFZFbtRUcAK4WGzB/yvN35tln7d5bb+XBqIq9Nc37loJ6uyntamqgbe
2YsG+dzxHenqxyCynS4nyUBVCxf0E2zuKssF9AIyjOiaTrg3ziFobnIquEmniXpuDnoW
0nEvurk88rN8Qm04jhL03oWeJgW2yh7icCs/6q/xLELZtq6RsDZB2eiL6Jqhn2xHZffM
ICkG3z3JnFgPksuEIKKk5msw+KWj7qmtjYoA6Y8hNrjBqNNIsYS73KogyPNmifl8MlG6
pQmQ==
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=oyoynKeIIprCD1jlo7eR+tDhfz6nYpFFtHJPAeoquj4=;
b=QixS9Pg0zjQFZL278bftt+uBIXtFUIsDWxmOGoUWEo4B/jsY4Jqq+9Dhfmd9o/v8wP
mVGJWynKeGYO6XiwpbQsKVQNgvF8Wb5DVdWDCYBb5GcmomPdXdIfq34cESvtl3sul8Tl
NT/4diJ7nrXwzTWaY2KM243H2sHGOfHBNerK+LiIQzqijTvaZTBj94kZT8tk2Y/Ke4L/
AtJAV7ePWzczB1I7+WRCv1xeNhQuvUaUtKzDZFfnHHcG1Y/Xs5gy5ngq/GawfS9s/QFM
4HLBP/az8SIY9AU+JDLK/80XZHLJ4pNmenpNF9We42PGAzwiJeKQEe6QT8N2jcUPNgbU
zpog==
X-Gm-Message-State: ALyK8tJ2lNQSrteDYQDKx2CppwgtEXPVsceVnajid21KcbOy6iF4pkuKgyMyBxVaiPH9Fg==
X-Received: by 10.194.22.72 with SMTP id b8mr5344132wjf.74.1467156875630;
Tue, 28 Jun 2016 16:34:35 -0700 (PDT)
Received: from [10.114.7.71] ([41.33.219.246])
by smtp.gmail.com with ESMTPSA id
r130sm1178472wmf.20.2016.06.28.16.34.34
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 28 Jun 2016 16:34:35 -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: <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
Date: Wed, 29 Jun 2016 01:34:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D317F7C9-C645-455F-8BA6-EB9F6D09F39F@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
<20160628182202.GA5519@fedora-21-dvm>
<D40F9E9D-DB6C-4083-A9E8-C5EBC363DB30@voskuil.org>
<20160628201447.GA1148@fedora-21-dvm>
<4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org>
<20160628203605.GA1328@fedora-21-dvm>
<E8335291-7142-4E21-A1E2-76F387426741@voskuil.org>
<CAAS2fgRGbnH-NtPRdLe0yhFSoqJ7b6O25LfyGv_ULHhy8bBSpg@mail.gmail.com>
<7F95A7F5-848C-4EA6-9503-C48F45AC1C34@voskuil.org>
<CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@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: Tue, 28 Jun 2016 23:34:37 -0000
>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:=
>>=20
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil <eric@voskuil.org> wrote:
>> Passing the session ID out of band is authentication. As this is explicit=
ly not part of BIP151 it cannot be that BIP151 provides the tools to detect a=
attack (the point at issue).
>=20
> It provides the ID, the rest is meat.
The rest is "authentication".
> Users can compare session IDs
> via whatever communications channels they already use after the fact
> and discover if they were or are being MITMed.
>=20
>>>> It requires a secure channel and is authentication. So BIP151 doesn't p=
rovide the tools to detect an attack, that requires authentication. A genera=
l requirement for authentication is the issue I have raised.
>>>=20
>>> One might wonder how you ever use a Bitcoin address, or even why we migh=
t guess these emails from "you" aren't actually coming from the NSA.
>>=20
>> The sarcasm is counterproductive Greg. By the same token I could ask how y=
ou ever use Bitcoin given that the P2P protocol is not encrypted or authenti=
cated.
>=20
> I think I was unclear. A bitcoin address needs to be sent over a secure ch=
annel, which we do not provide. Yet sending funds to addresses instead of an=
yone_can_spend is pretty useful.
>=20
> Similarly, I can guess that messages claiming to you are probably from you=
when many people can independently check, even if they don't usually. The f=
act tampered messages might be detected is a big disincentive from trying.
You were perfectly clear. Did I give some indication that I did not understa=
nd what you meant?
>> The blockchain and mempool are a cache of public data. Transmission of a p=
ayment address to a payer is not a comparable scenario.
>=20
> The precise timing and ordering of transactions being relayed is _not_
> public data.
Posting txs to the network is a client-server scenario. The set of txs arriv=
ing at an arbitrary node, including the order of arrival, is by definition p=
ublic information. The only possible way it could be considered private is i=
f the entire network was private.
So where does the private timing become public? First hop, second, third?
Encryption and authentication cannot prevent timing attacks against a person=
posting txs to the network unless the entire network is "secured". That is n=
ot possible without centralized access control.
Encrypting the P2P network doesn't resolve this problem, nor does authentica=
tion, nor does Tor. I would prefer we advance an actual solution to this sig=
nificant problem than advance a false sense of security while creating both c=
omplexity and the likely evolution of node identity.
e=
|
