MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

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