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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0BB5426C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 13:03:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF69E16C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 13:03:21 +0000 (UTC)
Received: by mail-lf0-f49.google.com with SMTP id l188so54940669lfe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 06:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ROrds7l1WYDmo8CTCNuZfhPVBdSp1nipPSKkcdGfPNk=;
b=EC6wLEYyhBA5/hxwJZhBgBRIIuS60xGp2z1bq7bmxUGsrW8hvWqP/bCIRc/IxbO/HM
dG4Do4yQvsAYeKxTNlhuWyk3tHCIIOwD42HAyJHO2vCFRj7MG3zqxrucckTVpYLueKEN
6vmY5Ev9rCLzXtCYMutCLFdYhpjtwHzJHuQ4+cjpDcs38ETfUN3iPfOogdzJMuOYyVWT
d4nPIpRX20MXs77hQaImFgu1KYW5eTjk3rWFeCopA9JvKBEhrz/QoXk71rzHFTVY2/B+
vRsYCb7vBaqUJbUjecV/xzb0sM4JfufdBzadBsi4+PWX0VXC8rpIGFJbTlRcsbJ0ct0T
RpSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=ROrds7l1WYDmo8CTCNuZfhPVBdSp1nipPSKkcdGfPNk=;
b=eSEPQN7QAj8xnxo6zxdpPWDuCmwryBBttAS1OnDAWRYy9RFzfj8bGrZZy8y8Vg57QI
pxBuWW8W/T5XF/8i3pm7oYpZPtDh6VDJgr+5WOvmUvVEYQVwOeSU7lrg4N8NjtuwM3WH
tpo4lRj4KcuCovYHpKokBJN/VfZMMI8qyakE//iWhcaLD6fW4IZtBBhLxwuufvR+fVxS
IlSpi4D/757zqBZ/YCu5WkU6gNg7MO47NIOpBBkSIuB488WNO/WuyFTPhWadpXjjS5+V
StP+KAw8lIfNYtBoMGa+LCVyxEEp6P/uVN39bJ6oy6ZXILphdei+L/ftAgc4avxNIUHo
74mQ==
X-Gm-Message-State: ALyK8tIiYpPAyQC1ko7FS7X/4DbSyEHmZ5ncB0VUaXsCVwlI63G9zDTA6T7nw0EtU1TnxRtcMsIHT5vEQxt5kw==
X-Received: by 10.25.40.8 with SMTP id o8mr4437383lfo.22.1467291799854; Thu,
30 Jun 2016 06:03:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.180.101 with HTTP; Thu, 30 Jun 2016 06:03:18 -0700 (PDT)
In-Reply-To: <CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
<CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
<CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 30 Jun 2016 15:03:18 +0200
Message-ID: <CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: Thu, 30 Jun 2016 13:03:23 -0000
On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The proliferation of node identity is my primary concern - this relates to privacy and the security of the network.
I think this is a reasonable concern.
However, node identity is already being used widely, and in a very
inadvisable way:
* Since forever there have been lists of 'good nodes' to pass in
addnode= configuration options.
* Various people run multiple nodes in different geographic locations,
peering with each other.
* Various pieces of infrastructure exist that relies on connecting to
well-behaving nodes (miner relay networks, large players peering
directly with each other, ...)
* Several lightweight clients support configuring a trusted host to connect to.
Perhaps you deplore that fact, but I believe it is inevitable that
different pieces of the network will make different choices here. You
can'tg prevent people from create connections along preexisting trust
lines. That does not mean that the network as a whole relies on first
establishing trust everywhere.
And I do think there are advantages.
BIP 151 on its own gives you opportunistic encryption. You're very
right to point out that this does not give you protection from active
attackers, and that active attacking is relatively easy through sybil
attacks. I still prefer my attacker to actually do that over just
listening in on my connection. And yes, we should also work on
improving the privacy nodes and wallets have orthogonal to encryption,
but nothing will make everything perfectly private.
BIP 151 plus a simple optional pre-shared-secret authentication
extension can improve upon pure IP-based authentication, as well as
simplify things like SSL tunnels, and onion addresses purely used as
identity. This will still require explicit configuration, but not more
than now.
BIP 151 plus a non-leaking public key authentication scheme (where
peers can query "are you the peer with pubkey X?" but don't learn
anything if the answer is no) with keys specific to the IP addresses
can give a TOFU-like security. Nodes already remember IP addresses
they've succesfully interacted with in the past, and ban IP addresses
that misbehave. Being able to tell whether a node you connect to is
the same as one you've connected to before is a natural extension of
this, and does not require establishing any real-world identity beyond
what we're already implicitly relying on.
Perhaps these use cases and their security assumptions should be
spelled out more clearly in the BIP. If there is a misunderstanding,
it should be clearly stated that BIP 151 is only a building block for
further improvements
> Secondarily I am concerned about users operating under a false assumption about the strength of privacy.
This is a widespread problem, but it exists far outside the scope of
this proposal. The privacy properties of Bitcoin are often
misrepresented and even used as advertizements. The solution is
education, not avoiding improvements because they may be
misunderstood.
> The complexity of the proposed construction is comparable to that of Bitcoin itself.
I really think this is an exaggeration. It's a diffie-hellman
handshake and a stream cipher (both very common constructions), that
apply to individual connections. There are no consensus risks nor a
requirement for coordinated change through the network. The
cryptographic code can be directly reused from a well-known project
(OpenSSH), and is very small in size.
--
Pieter
|
