Re: [bitcoin-dev] BIP 151

From: Eric Voskuil <eric@voskuil•org>
To: Jonas Schnelli <dev@jonasschnelli•ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Tue, 28 Jun 2016 18:45:58 +0200	[thread overview]
Message-ID: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> (raw)
In-Reply-To: <577234A4.3030808@jonasschnelli.ch>

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:
> 
> Hi Eric
> 
>> I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it.
>> 
>> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features).
>> 
>> It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol.
>> 
>> The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted 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.
> 
> 2) Peer censorship
> MITM can remove or add entries from a "addr" message.
> 
> 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 permissionless network. This is accepted in the BIP (and your follow-up reply).

> 4) SPV
> For obvious reasons regarding BF (see BIP or above).
> 
> 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 authentication in a client-server blockchain protocol.

> I would not reduce BIP151 to only solve the BF privacy/censorship problem.
> 
> If we agree that censorship-resistance is one of the main properties of Bitcoin,

We do.

> then we should definitively use a form of end-to-end encryption between nodes. 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 case where encryption (and therefore authentication) is pervasive.

As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates 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 challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.

In my opinion this question has not received sufficient consideration to warrant 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, if 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 the checksum seems like a better option. But again, it is moot if it creates an 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 on a future BIP, making BIP151 incomplete without it. I think we can agree that 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>
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev