Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
Date: Wed, 29 Jun 2016 01:33:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:

>> I understand the use, when coupled with a yet-to-be-devised identity syst=
em, with Bloom filter features. Yet these features
>=20
> This is a bit of a strawman, you've selected a single narrow usecase which=
 isn't proposed by the BIP and then argue it is worthless. I agree that exam=
ple doesn't have much value (and I believe that
> eventually the BIP37 bloom filters should be removed from the protocol).

I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as i=
ts justifying scenario.

> Without something like BIP151 network participants cannot have privacy for=
 the transactions they originate within the protocol against network observe=
rs.

And they won't get it with BIP151 either. Being a peer is easier than observ=
ing the network. If one can observe the encrypted traffic one can certainly u=
se a timing attack to determine what the node has sent.

> Even if, through some extraordinary effort, their own first hop is encrypt=
ed, unencrypted later hops would rapidly
> expose significant information about transaction origins in the network.

As will remain the case until all connections are encrypted and authenticate=
d, and all participants are known to be good guys. Starting to sound like PK=
I?

> Without something like BIP151 authenticated links are not possible, so
> manually curated links (addnode/connect) cannot be counted on to provide p=
rotection against partitioning sybils.

If we trust the manual links we don't need/want the other links. In fact ret=
aining the other links enables the attack you described above. Of course the=
re is no need to worry about Sybil attacks when all of your peers are authen=
ticated. But again, let us not ignore the problems of requiring all peers on=
 the network be authenticated.

> Along the way BIP151 appears that it will actually make the protocol faste=
r.
>=20
>> Given that the BIP relies on identity
>=20
> This is untrue. The proposal is an ephemerally keyed opportunistic
> encryption system. The privacy against a network observer does not depend o=
n authentication, much less "identity".  And when used with authentication a=
t all it makes interception strongly detectable after the fact.

Maybe I was insufficiently explicit. By "relies on identity" I meant that th=
e BIP is not effective without it. I did not mean to imply that the BIP itse=
lf implements an identity scheme. I thought this was clear from the context.=


>> The BIP does not [...] contemplate the significant problems associated wi=
th key distribution in any identity system
>=20
> Because it does not propose any "identity system" or authorization (also, I=
 object to your apparent characterization of authentication as as an 'identi=
ty system'-- do you also call Bitcoin addresses an identity system?).

Please read more carefully what I wrote. I did not characterize authenticati=
on as an identity system. I proposed that key distribution has significant p=
roblems, and used identity systems as an example of systems with such proble=
ms. I could just have easily written "authentication systems", (and probably=
 should have).

> That said, manually maintaining adds nodes to your own and somewhat truste=
d nodes is a recommend best practice for miners and other high value systems=
 which is rendered much less effective due to a lack of
> authentication, there is no significant key distribution problem in that c=
ase

This is the only legitimate scenario that I am aware of. Doing this by IP ad=
dress (as we do) is weak if there is no VPN.

Yet this scenario is very different than general authentication. This scenar=
io is a set of nodes that is essentially a single logical node from the pers=
pective of the Bitcoin security model. One entity controls the validation ru=
les, or is collaborating with another entity to do so.

My concern is that a general authentication requirement expands this single l=
ogical node and gives control over if to the entity that controls key distri=
bution - the hard problem that hasn't been addressed.

If there is no such entity restricting access to the network (which hopefull=
y we can assume) then there is no reason to expect any effective improvement=
, since nodes will necessarily have to connect with anonymous peers. Anyone w=
ith a node and the ability to monitor traffic should remain very effective.

> and I expect the future auth BIP (Jonas had one before, but it was put asi=
de for now to first focus on the link layer encryption)
> to address that case quite well.

Defining an auth implementation is not a hard problem, nor is it the concern=
 I have raised.

e=