[bitcoin-dev] BIP 151

[Eric Voskuil]

continued from previous post...

> On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> Hi Eric
> 
> 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:
> 
>> 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).
> 
> 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 in nature. Despite being possible it is not a valid use case for a full node to make BF requests to another node.

One client to multiple servers is still client-server for the sake of this discussion. The nature of the P2P protocol is synchronization of content between all nodes/peers. If the protocol is asymmetric the semantics, and therefore 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 scenario and is a hack when done (full disclosure, bx provides both P2P and client-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/keys 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 discussion. Libbitcoin provides fee estimation by monitoring broadcast penetration 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 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.
> 
> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?

TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.

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

>> 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.
> 
> 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 solvable 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>