Re: [bitcoin-dev] BIP 151

[Eric Voskuil <eric@voskuil.org>]

Pieter, these are in my opinion very reasonable positions. I've made some observations inline.

> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 
> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> The proliferation of node identity is my primary concern - this relates to privacy and the security of the network.
> 
> I think this is a reasonable concern.
> 
> However, node identity is already being used widely, and in a very
> inadvisable way:
> * Since forever there have been lists of 'good nodes' to pass in
> addnode= configuration options.
> * Various people run multiple nodes in different geographic locations,
> peering with each other.
> * Various pieces of infrastructure exist that relies on connecting to
> well-behaving nodes (miner relay networks, large players peering
> directly with each other, ...)

Yes, libbitcoin also provides these options on an IP basis.

> * Several lightweight clients support configuring a trusted host to connect to.

I explicitly exclude client-server behavior as I believe the proper resolution is to isolate clients from the P2P protocol. Libbitcoin does this already.

> Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can't prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere.

Of course, the network operates just fine without universal trust. My concern is not that it is required, but that it may grow significantly and will have a tendency to gravitate towards more effective registration mechanisms for what is a "good" peer. Even an informal but pervasive web of trust may make it difficult for untrusted parties to connect.

> And I do think there are advantages.
> 
> BIP 151 on its own gives you opportunistic encryption. You're very right to point out that this does not give you protection from active attackers, and that active attacking is relatively easy through sybil attacks. I still prefer my attacker to actually do that over just listening in on my connection.

We agree, and the ease of this attack must be acknowledged. And given that the protection is weak it is not unreasonable to consider the potential downside of creeping node identity.

> And yes, we should also work on improving the privacy nodes and wallets have orthogonal to encryption, but nothing will make everything perfectly private.

I agree, and I doubt this proposal will have much impact on an advanced persistent threat, or even lesser threats. People should understand that there is both a risk and a limited benefit to this proposal.

> BIP 151 plus a simple optional pre-shared-secret authentication extension can improve upon pure IP-based authentication, as well as simplify things like SSL tunnels, and onion addresses purely used as identity. This will still require explicit configuration, but not more than now.

I agree - I consider tunneling the legitimate use case for this proposal. Yet when nodes become closely coupled they are not fully independent. I have a concern with these practices being promoted for general use while at the same time being strongly implemented.

> BIP 151 plus a non-leaking public key authentication scheme (where peers can query "are you the peer with pubkey X?" but don't learn anything if the answer is no) with keys specific to the IP addresses can give a TOFU-like security. Nodes already remember IP addresses they've succesfully interacted with in the past, and ban IP addresses that misbehave. Being able to tell whether a node you connect to is the same as one you've connected to before is a natural extension of this,

With this I disagree. There is no way to know that a node is one you have connected to previously unless that node wants you to know (apart from relying on the IP address). This is of no value in detecting misbehaving nodes that do not want to be detected. Ones that don't care (eg broken nodes) can be sufficiently managed by IP address.

> and does not require establishing any real-world identity beyond what we're already implicitly relying on.
> 
> Perhaps these use cases and their security assumptions should be spelled out more clearly in the BIP.

Absolutely.

> If there is a misunderstanding, it should be clearly stated that BIP 151 is only a building block for further improvements
> 
>> Secondarily I am concerned about users operating under a false assumption about the strength of privacy.
> 
> This is a widespread problem, but it exists far outside the scope of this proposal. The privacy properties of Bitcoin are often
> misrepresented and even used as advertizements. The solution is education, not avoiding improvements because they may be misunderstood.

Yes, let's not make it worse. This is a secondary concern. I remain primarily concerned about growth of node identity in a vain attempt to make transaction submission private in the P2P protocol (and to patch the other client-server features, specifically Bloom filters). As you imply, we cannot stop people from turning Bitcoin into a private network - but let's not facilitate it either.

>> The complexity of the proposed construction is comparable to that of Bitcoin itself.
> 
> I really think this is an exaggeration. It's a diffie-hellman handshake and a stream cipher (both very common constructions), that apply to individual connections. There are no consensus risks nor a
> requirement for coordinated change through the network. The
> cryptographic code can be directly reused from a well-known project
> (OpenSSH), and is very small in size.

I believe you have misinterpreted my comments on distributed anonymous credentials (and the like) as commentary on the construction of BIP151 (and a subsequent auth proposal). As such your observation that it is exaggerated would make sense, but it is not what I intended. Encryption and auth are straightforward. Preventing bad nodes from participating in an anonymous distributed system is not.

e