Re: [bitcoin-dev] BIP 151

[Gregory Maxwell <greg@xiph.org>]

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

Without something like BIP151 network participants cannot have privacy
for the transactions they originate within the protocol against
network observers. 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.

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.

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.

> 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?).

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