From: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
Date: Tue, 28 Jun 2016 18:45:58 +0200
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
In-Reply-To: <577234A4.3030808@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

Hi Jonas, I'll follow up in your second reply as well. Responses inline:

> On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>=20
> Hi Eric
>=20
>> I haven't seen much discussion here on the rationale behind BIP 151. Apol=
ogies if I missed it. I'm trying to understand why libbitcoin (or any node) w=
ould want to support it.
>>=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
>> 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
>> 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.

> In my opinion, the question should be "why would you _not_ encrypt".

1) creation of a false sense of security
2) as a tradeoff against anonymity
3) benefit does not justify cost

> 1) Transaction censorship
> ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed
> transactions. Regardless if you are a miner or a validation/wallet node.
>=20
> 2) Peer censorship
> MITM can remove or add entries from a "addr" message.
>=20
> 3) Fingerprinting
> ISPs or any other MITM can intercept/inject fingerprinting relevant
> messages like "mempool" to analyze the bitcoin network.

Encryption alone cannot protect against a MITM attack in an anonymous and pe=
rmissionless network. This is accepted in the BIP (and your follow-up reply)=
.

> 4) SPV
> For obvious reasons regarding BF (see BIP or above).
>=20
> 5) Goundwork for a "client-server" model over the P2P channel
> Fee estimation, bloom-filters, or any other message type that requires
> authentication.

I do not challenge the usefulness and appropriateness of encryption with aut=
hentication in a client-server blockchain protocol.

> I would not reduce BIP151 to only solve the BF privacy/censorship problem.=

>=20
> If we agree that censorship-resistance is one of the main properties of Bi=
tcoin,

We do.

> then we should definitively use a form of end-to-end encryption between no=
des. Built into the network layer.

This is the assumption that I'm questioning.

> There are plenty of other options to solve this problem. stunnel,
> Bernsteins CurveCP, VPN, etc. which are available since years.
> But the reality has shown that most bitcoin traffic is still unencrypted.

The question arises from concern over the security of the network in the cas=
e where encryption (and therefore authentication) is pervasive.

As you point out, anyone can set up a private network of nodes today. These n=
odes must also connect to the permissionless network to maintain the chain. T=
hese nodes constitute a trust zone within Bitcoin. This zone of exclusion op=
erates as a single logical node from the perspective of the Bitcoin security=
 model (one entity controls the validation rules for all nodes).

Widespread application of this model is potentially problematic. It is a non=
-trivial problem to design a distributed system that requires authentication=
 but without identity and without central control. In fact this may be more c=
hallenging than Bitcoin itself. Trust on first use (TOFU) does not solve thi=
s problem.

In my opinion this question has not received sufficient consideration to war=
rant proceeding with a network encryption scheme (which concerns me as well,=
 but as I consider it premature I won't comment).

> Example: IIRC non of the available SPV wallets can "speak" on of the
> possible encryption techniques. Encrypting traffic below the application
> layer is extremely hard to set up for non-experienced users.

Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, i=
f the proposal creates an insecurity its ease of deployment is moot.

> On top of that, encryption allows us to drop the SHA256 checksum per p2p
> message which should result in a better performance on the network layer
> once BIP151 is deployed.

I would not consider this a performance enhancing proposal. Simply dropping t=
he checksum seems like a better option. But again, it is moot if it creates a=
n insecurity.

> I agree that BIP151 _must_ be deployed together with an authentication
> scheme (I'm working on that) to protect again MITM during encryption
> initialization.

At a minimum I would propose that you modify BIP151 to declare a dependency o=
n a future BIP, making BIP151 incomplete without it. I think we can agree th=
at it would be unadvisable to deploy (and therefore to implement) encryption=
 alone.

I'll respond to the question of authentication in your follow-up post.

e

> ---
> </jonas>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev