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
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BEE39958
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 08:26:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 1AFE616A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 08:26:15 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 0B9572E604A5; Tue, 28 Jun 2016 10:26:13 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch
[87.102.140.182]) by server3 (Postfix) with ESMTPSA id 4AC4E2D001D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 10:26:13 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <577234A4.3030808@jonasschnelli.ch>
Date: Tue, 28 Jun 2016 10:26:12 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a"
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 08:26:15 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a
Content-Type: multipart/mixed; boundary="5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <577234A4.3030808@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP 151
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
In-Reply-To: <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
--5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi Eric
> I haven't seen much discussion here on the rationale behind BIP 151. Ap=
ologies if I missed it. I'm trying to understand why libbitcoin (or any n=
ode) would want to support it.
>=20
> I understand the use, when coupled with a yet-to-be-devised identity sy=
stem, with Bloom filter features. Yet these features are client-server in=
nature. Libbitcoin (for example) supports client-server features on an i=
ndependent port (and implements a variant of CurveCP for encryption and i=
dentity). My concern arises with application of identity to the P2P proto=
col (excluding Bloom filter features).
>=20
> It seems to me that the desire to secure against the weaknesses of BF i=
s being casually generalized to the P2P network. That generalization may =
actually weaken the security of the P2P protocol. One might consider the =
proper resolution is to move the BF features to a client-server protocol.=
>=20
> The BIP does not make a case for other scenarios, or contemplate the si=
gnificant problems associated with key distribution in any identity syste=
m. Given that the BIP relies on identity, these considerations should be =
fully vetted before heading down another blind alley.
In my opinion, the question should be "why would you _not_ encrypt".
1) Transaction censorship
ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
transactions. Regardless if you are a miner or a validation/wallet node.
2) Peer censorship
MITM can remove or add entries from a "addr" message.
3) Fingerprinting
ISPs or any other MITM can intercept/inject fingerprinting relevant
messages like "mempool" to analyze the bitcoin network.
4) SPV
For obvious reasons regarding BF (see BIP or above).
5) Goundwork for a "client-server" model over the P2P channel
Fee estimation, bloom-filters, or any other message type that requires
authentication.
I would not reduce BIP151 to only solve the BF privacy/censorship problem=
=2E
If we agree that censorship-resistance is one of the main properties of
Bitcoin, then we should definitively use a form of end-to-end encryption
between nodes. Built into the network layer.
There are plenty of other options to solve this problem. stunnel,
Bernsteins CurveCP, VPN, etc. which are available since years.
But the reality has shown that most bitcoin traffic is still unencrypted.=
Example: IIRC non of the available SPV wallets can "speak" on of the
possible encryption techniques. Encrypting traffic below the application
layer is extremely hard to set up for non-experienced users.
On top of that, encryption allows us to drop the SHA256 checksum per p2p
message which should result in a better performance on the network layer
once BIP151 is deployed.
I agree that BIP151 _must_ be deployed together with an authentication
scheme (I'm working on that) to protect again MITM during encryption
initialization.
---
</jonas>
--5qHNA5XS620cvTbWMSkP0dg5xLvFphD8H--
--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXcjSkAAoJECnUvLZBb1PsLvwP/0vgFiLeh8+YaUB9WY47Yogq
5yHfOJgCELZhrDsVLYm7b45K8MoJ+ASTw7PMBIfwyBdOqdKIO5JhC6oxwxX/fOTV
PynJossiRt+5aV5xPWcwM0H1PIuM3xRXQC429QG3DbyMLhZldS5oP3BQZ58Nl4rt
8C6G1o8BEJT1PXl8cWNo6M3a8IXCzsV3d5h7VS4ei7X5JEcrKZb1jHFLyizfa0qH
nEIQioyH3Qmx6mN1VWuwn/lIzVLB3bxb9FSfQnrLkjhHFT9r0BkewhYiPkbbzuhW
25O3hBn8ilAWph98RTl0Tgp8aZhso+1AfkPZlbtBSMnHtTePq5xiy1YX1RCF3KUx
1igDIonHAzOLyC9s8/NTLEYTKkFp7QKF2LqYLWpdWEAzuJ04hqCOii2OMasc1jll
GPgPb34UbyEbt9igwmp4c567MGl4wFx5H9Q7BiV279XIxkkmCFPanCH5vq0nWkvM
3BO6N1dx5OnOl+BIdkL6e0GBAX9Fm4pKJbjyMrR/a6YdQHf14we5B56e0BCTwJ+T
9UyURFs55oYns5BVV6zhjcu33nuHaPJasgb3yVIfb9GGvdkYY5h+CsJlIH79Pl+J
hniyL6cCYYUGbH4gRBfo/j+mWovi0+8ugn844mBbysPFeYuIN2iOh9C6bikFXaqZ
dYhvqjTYhJHsxTSLly5Q
=PAqa
-----END PGP SIGNATURE-----
--5Mwj3D6vvqbmkODoP5NfJ31RdxhGowE6a--
|
