Re: [bitcoin-dev] BIP 151

[Eric Voskuil <eric@voskuil.org>]

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>> I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features
> 
> This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have much value (and I believe that
> eventually the BIP37 bloom filters should be removed from the protocol).

I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as its justifying scenario.

> Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers.

And they won't get it with BIP151 either. Being a peer is easier than observing the network. If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent.

> Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly
> expose significant information about transaction origins in the network.

As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI?

> Without something like BIP151 authenticated links are not possible, so
> manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils.

If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated.

> Along the way BIP151 appears that it will actually make the protocol faster.
> 
>> Given that the BIP relies on identity
> 
> This is untrue. The proposal is an ephemerally keyed opportunistic
> encryption system. The privacy against a network observer does not depend on authentication, much less "identity".  And when used with authentication at all it makes interception strongly detectable after the fact.

Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context.

>> The BIP does not [...] contemplate the significant problems associated with key distribution in any identity system
> 
> Because it does not propose any "identity system" or authorization (also, I object to your apparent characterization of authentication as as an 'identity system'-- do you also call Bitcoin addresses an identity system?).

Please read more carefully what I wrote. I did not characterize authentication as an identity system. I proposed that key distribution has significant problems, and used identity systems as an example of systems with such problems. I could just have easily written "authentication systems", (and probably should have).

> That said, manually maintaining adds nodes to your own and somewhat trusted nodes is a recommend best practice for miners and other high value systems which is rendered much less effective due to a lack of
> authentication, there is no significant key distribution problem in that case

This is the only legitimate scenario that I am aware of. Doing this by IP address (as we do) is weak if there is no VPN.

Yet this scenario is very different than general authentication. This scenario is a set of nodes that is essentially a single logical node from the perspective of the Bitcoin security model. One entity controls the validation rules, or is collaborating with another entity to do so.

My concern is that a general authentication requirement expands this single logical node and gives control over if to the entity that controls key distribution - the hard problem that hasn't been addressed.

If there is no such entity restricting access to the network (which hopefully we can assume) then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers. Anyone with a node and the ability to monitor traffic should remain very effective.

> and I expect the future auth BIP (Jonas had one before, but it was put aside for now to first focus on the link layer encryption)
> to address that case quite well.

Defining an auth implementation is not a hard problem, nor is it the concern I have raised.

e