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
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0717B69
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 23:24:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com
[209.85.218.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B1CF8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 23:24:05 +0000 (UTC)
Received: by mail-oi0-f44.google.com with SMTP id h6so76887475oia.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 16:24:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=aoRS1595AxmWDqugrfg+aUmyWpI6O8nIfaUHeMlE9hU=;
b=fI7rgMkkWV3/6AXz1vGdL5k/isg+suWOEk/wnkAHdn61FR4MGjQvTpp8iRulkULaI/
DcyS3qdeidRDpWCAd4mKpPbF64GfuSLk8XrODKcQ4gs2rt2g7S/dt5bhqYsrnWTANYsH
3LgyeMnOlHpk3fEiu7YWsGPgWlSPegukMrhOXwS9cvwMCa8BCzoRqsS434yozOgTVsUc
Y36wa1PKRdZ0CAtVT2J0oQRzNtXg14023WnaKiUisOaSG30jGNSuwofDQWfWwx5ewG2Y
SeXPFgqOh/maBjPDoWdMhLFMaM8wYo8WKO2dy5FRNZfnwl/4tq93tTSSliRvtXAReo/w
pH1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=aoRS1595AxmWDqugrfg+aUmyWpI6O8nIfaUHeMlE9hU=;
b=jvsmXx3L/QQ9FJKZ5aa6CzBI2pWonIbNcl11eebvAUG8Dp98e8kXkq+k0ItYTj44/t
jLMCH2h3rG/szgCF9WixuYJ4ndsw1uoo7AFHvb/77lNCEBPLCzJP+MuL9MpKVJuJIDpE
G7AM/8pI5pIq2KDt2fKsIRylmSEQy2i64SbgSZ+OR93O1ycWPQ5z3hKPQs8dz/myuyTW
pN9kbS8JM7zNWUTpLub2trWAKRW1BiQ4m9cCLael8LOMDevwD3+JdZwoam0FrHb7kYrE
sTQ9q9SMoWYrSImTCFfKP9CPsUn2Z0hRsURxG1FtoTZeLosaS6NQ3RXRw5v3Cbvrjb40
v3aA==
X-Gm-Message-State: AD7BkJJZ63LoRopN1aWc3k1KxQ1Kkgp8Qdg8iv9yQ4tcPWHndTtC0srNaHobkg5wZqgXYhZ1wy2cqbGHuiHjRQ==
X-Received: by 10.202.90.3 with SMTP id o3mr9174879oib.96.1459034644622; Sat,
26 Mar 2016 16:24:04 -0700 (PDT)
MIME-Version: 1.0
References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
<56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp>
In-Reply-To: <4517402.JLxTDjem5X@garp>
From: James MacWhyte <macwhyte@gmail.com>
Date: Sat, 26 Mar 2016 23:23:54 +0000
Message-ID: <CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
To: Tom <tomz@freedommail.ch>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d5edcb53448052efbf9c9
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Sun, 27 Mar 2016 08:17:23 +0000
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 26 Mar 2016 23:24:08 -0000
--001a113d5edcb53448052efbf9c9
Content-Type: text/plain; charset=UTF-8
On Sat, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:
> > An encrypted channel together with a trusted full node would finally
> > allow to have a secure and save SPV communication.
>
> I guess my question didn't get across.
>
> Why would you want to make your usecase do connections over the peer2peer
> (net.cpp) connection at all?
>
> Mixing messages that are being sent to everyone and encrypted messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
>
>
I agree doing it out-of-band is the easiest solution for people who need
this privacy right now, but I do like the idea of adding this feature as
the number of SPV wallets is going to increase. I think the best way to
organize things would be to give encrypted messages their own port number,
similar to how http vs. https works.
We don't want two networks to develop, separated by which nodes support
encryption and which don't, so ideally nodes would rebroadcast messages
they receive on both (encrypted and non-encrypted) channels. This would
essentially double the required bandwidth of the network, which is
something to think about.
> > > Also, you didn't actually address the attack-vector.
> >
> > Which attack-vector?
>
> The statistical attack I mentioned earlier. Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long
> as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113d5edcb53448052efbf9c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat=
, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev <<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Friday 25 Mar 2016 19:=
43:00 Jonas Schnelli via bitcoin-dev wrote:<br>
> An encrypted channel together with a trusted full node would finally<b=
r>
> allow to have a secure and save SPV communication.<br>
<br>
I guess my question didn't get across.<br>
<br>
Why would you want to make your usecase do connections over the peer2peer<b=
r>
(net.cpp) connection at all?<br>
<br>
Mixing messages that are being sent to everyone and encrypted messages is<b=
r>
asking for trouble.<br>
Making your private connection out-of-band would work much better.<br>
<br></blockquote><div><br></div><div>I agree doing it out-of-band is the ea=
siest solution for people who need this privacy right now, but I do like th=
e idea of adding this feature as the number of SPV wallets is going to incr=
ease. I think the best way to organize things would be to give encrypted me=
ssages their own port number, similar to how http vs. https works.<br><br>W=
e don't want two networks to develop, separated by which nodes support =
encryption and which don't, so ideally nodes would rebroadcast messages=
they receive on both (encrypted and non-encrypted) channels. This would es=
sentially double the required bandwidth of the network, which is something =
to think about.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > Also, you didn't actually address the attack-vector.<br>
><br>
> Which attack-vector?<br>
<br>
The statistical attack I mentioned earlier.=C2=A0 Which comes from knowing =
which<br>
plain text messages are being sent over the encrypted channel, So as long a=
s<br>
you keep saying you want to encrypt data that identical copies of are being=
<br>
sent to other nodes at practically the same time, you will keep being<br>
vulnerable to that.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--001a113d5edcb53448052efbf9c9--
|
