Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
Date: Thu, 30 Jun 2016 17:10:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0932A659-6BE0-441F-AD05-ED846BBE7C80@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>
	<CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

Pieter, these are in my opinion very reasonable positions. I've made some ob=
servations inline.

> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote=
:
>=20
> 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 t=
o privacy and the security of the network.
>=20
> I think this is a reasonable concern.
>=20
> 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=3D 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, ...)

Yes, libbitcoin also provides these options on an IP basis.

> * Several lightweight clients support configuring a trusted host to connec=
t to.

I explicitly exclude client-server behavior as I believe the proper resoluti=
on is to isolate clients from the P2P protocol. Libbitcoin does this already=
.

> Perhaps you deplore that fact, but I believe it is inevitable that differe=
nt pieces of the network will make different choices here. You can't prevent=
 people from create connections along preexisting trust lines. That does not=
 mean that the network as a whole relies on first establishing trust everywh=
ere.

Of course, the network operates just fine without universal trust. My concer=
n is not that it is required, but that it may grow significantly and will ha=
ve a tendency to gravitate towards more effective registration mechanisms fo=
r what is a "good" peer. Even an informal but pervasive web of trust may mak=
e it difficult for untrusted parties to connect.

> And I do think there are advantages.
>=20
> BIP 151 on its own gives you opportunistic encryption. You're very right t=
o point out that this does not give you protection from active attackers, an=
d that active attacking is relatively easy through sybil attacks. I still pr=
efer my attacker to actually do that over just listening in on my connection=
.

We agree, and the ease of this attack must be acknowledged. And given that t=
he protection is weak it is not unreasonable to consider the potential downs=
ide of creeping node identity.

> And yes, we should also work on improving the privacy nodes and wallets ha=
ve orthogonal to encryption, but nothing will make everything perfectly priv=
ate.

I agree, and I doubt this proposal will have much impact on an advanced pers=
istent threat, or even lesser threats. People should understand that there i=
s both a risk and a limited benefit to this proposal.

> BIP 151 plus a simple optional pre-shared-secret authentication extension c=
an improve upon pure IP-based authentication, as well as simplify things lik=
e SSL tunnels, and onion addresses purely used as identity. This will still r=
equire explicit configuration, but not more than now.

I agree - I consider tunneling the legitimate use case for this proposal. Ye=
t when nodes become closely coupled they are not fully independent. I have a=
 concern with these practices being promoted for general use while at the sa=
me time being strongly implemented.

> BIP 151 plus a non-leaking public key authentication scheme (where peers c=
an query "are you the peer with pubkey X?" but don't learn anything if the a=
nswer is no) with keys specific to the IP addresses can give a TOFU-like sec=
urity. Nodes already remember IP addresses they've succesfully interacted wi=
th in the past, and ban IP addresses that misbehave. Being able to tell whet=
her a node you connect to is the same as one you've connected to before is a=
 natural extension of this,

With this I disagree. There is no way to know that a node is one you have co=
nnected to previously unless that node wants you to know (apart from relying=
 on the IP address). This is of no value in detecting misbehaving nodes that=
 do not want to be detected. Ones that don't care (eg broken nodes) can be s=
ufficiently managed by IP address.

> and does not require establishing any real-world identity beyond what we'r=
e already implicitly relying on.
>=20
> Perhaps these use cases and their security assumptions should be spelled o=
ut more clearly in the BIP.

Absolutely.

> If there is a misunderstanding, it should be clearly stated that BIP 151 i=
s only a building block for further improvements
>=20
>> Secondarily I am concerned about users operating under a false assumption=
 about the strength of privacy.
>=20
> This is a widespread problem, but it exists far outside the scope of this p=
roposal. 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.

Yes, let's not make it worse. This is a secondary concern. I remain primaril=
y concerned about growth of node identity in a vain attempt to make transact=
ion submission private in the P2P protocol (and to patch the other client-se=
rver features, specifically Bloom filters). As you imply, we cannot stop peo=
ple from turning Bitcoin into a private network - but let's not facilitate i=
t either.

>> The complexity of the proposed construction is comparable to that of Bitc=
oin itself.
>=20
> I really think this is an exaggeration. It's a diffie-hellman handshake an=
d 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.

I believe you have misinterpreted my comments on distributed anonymous crede=
ntials (and the like) as commentary on the construction of BIP151 (and a sub=
sequent auth proposal). As such your observation that it is exaggerated woul=
d make sense, but it is not what I intended. Encryption and auth are straigh=
tforward. Preventing bad nodes from participating in an anonymous distribute=
d system is not.

e=