Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Message-Id: <2E638F35-D212-43B7-A9AB-7D7C33CFF781@voskuil.org>
Date: Tue, 28 Jun 2016 19:39:41 +0200
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577269E7.6020008@jonasschnelli.ch>
In-Reply-To: <577269E7.6020008@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

continued from previous post...

> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>=20
> Hi Eric
>=20
> Sorry for not directly addressing your points.

No problem. Thanks for the detailed replies.

> I try to be more precise in this follow up email:
>=20
>> I understand the use, when coupled with a yet-to-be-devised identity syst=
em, with Bloom filter features. Yet these features are client-server in natu=
re. Libbitcoin (for example) supports client-server features on an independe=
nt port (and implements a variant of CurveCP for encryption and identity). M=
y concern arises with application of identity to the P2P protocol (excluding=
 Bloom filter features).
>=20
> I think the bloom filter SPV usecase is not "pure client-server". SPV
> clients could request from/broadcast to multiple "trusted nodes".

I have referred to the Bloom filters messages. These are clearly asymmetric i=
n nature. Despite being possible it is not a valid use case for a full node t=
o make BF requests to another node.

One client to multiple servers is still client-server for the sake of this d=
iscussion. The nature of the P2P protocol is synchronization of content betw=
een all nodes/peers. If the protocol is asymmetric the semantics, and theref=
ore use cases, are different.

FWIW posting a transaction to the network can be done using the P2P protocol=
, connecting for a short period of time. But this is also a client-server sc=
enario and is a hack when done (full disclosure, bx provides both P2P and cl=
ient-server commands for tx posting). Broadcasting is naturally the behavior=
 of a full node.

> Trusted nodes could be nodes where the operators have shared identities/ke=
ys in advance over a different channel.

Yes, this is necessarily the case in order to prevent a MITM attack. This is=
 the basis of my concern.

> Further private p2p extensions (lets say a p2p form of the estimatefee
> command) are something which needs to be discussed first and not
> something that is encouraged or outlined in BIP151.

Sure, but then let us not make assumptions about it in the context of this d=
iscussion. Libbitcoin provides fee estimation by monitoring broadcast penetr=
ation using a client-server protocol with an optional subscription mechanism=
.

>> It seems to me that the desire to secure against the weaknesses of BF is b=
eing casually generalized to the P2P network. That generalization may actual=
ly weaken the security of the P2P protocol. One might consider the proper re=
solution is to move the BF features to a client-server protocol.
>=20
> I don't see reasons why BIP151 could weaken the security of the P2P networ=
k. Can you point out some specific concerns?

TOFU cannot prevent MITM attacks (the goal of the encryption). Authenticatio=
n requires a secure (trusted) side channel by which to distribute public key=
s. This presents what I consider a significant problem. If widespread, contr=
ol over this distribution network would constitute control over who can use B=
itcoin.

The effort to prevent censorship could actually enable it. I don't think it w=
ould get that far. Someone would point this out in the process of vetting th=
e authentication BIP, and the result would be the scrapping of BIP151.

>> The BIP does not make a case for other scenarios, or contemplate the sign=
ificant problems associated with key distribution in any identity system. Gi=
ven that the BIP relies on identity, these considerations should be fully ve=
tted before heading down another blind alley.
>=20
> BIP151 does not rely on identities. BIP151 does not use persisted keys
> (only ephemeral keys).

BIP 151 is incomplete without authentication.

> The authentication/identity system needs to be described in a another BIP.=

> But correct, BIP151 without a form of authentication/identity management
> is vulnerable to all sorts of MITM attacks and that's why I think BIP151
> must be deployed together with an p2p authentication scheme.

Agree, but my problem is that I do not believe we can assume this is a solva=
ble problem.

> Scope creeping and the risks of overspecifying is the main reason to
> focus on the "pure encryption part" in BIP151.

Understood, yet this is the basis of my blind alley comment.

e

> Thanks
> ---
> </jonas>