Subject: Re: [bitcoin-dev] BIP 151

From: Eric Voskuil <[email-masked]>
Date: Wed, 29 Jun 2016 01:34:33 +0200

>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell <[email-masked]> wrote:
>> 
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil <[email-masked]> wrote:
>> Passing the session ID out of band is authentication. As this is explicitly not part of BIP151 it cannot be that BIP151 provides the tools to detect a attack (the point at issue).
> 
> It provides the ID, the rest is meat.

The rest is "authentication".

> Users can compare session IDs
> via whatever communications channels they already use after the fact
> and discover if they were or are being MITMed.
> 
>>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>> 
>>> One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA.
>> 
>> The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated.
> 
> I think I was unclear. A bitcoin address needs to be sent over a secure channel, which we do not provide. Yet sending funds to addresses instead of anyone_can_spend is pretty useful.
> 
> Similarly, I can guess that messages claiming to you are probably from you when many people can independently check, even if they don't usually. The fact tampered messages might be detected is a big disincentive from trying.

You were perfectly clear. Did I give some indication that I did not understand what you meant?

>> The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario.
> 
> The precise timing and ordering of transactions being relayed is _not_
> public data.

Posting txs to the network is a client-server scenario. The set of txs arriving at an arbitrary node, including the order of arrival, is by definition public information. The only possible way it could be considered private is if the entire network was private.

So where does the private timing become public? First hop, second, third?

Encryption and authentication cannot prevent timing attacks against a person posting txs to the network unless the entire network is "secured". That is not possible without centralized access control.

Encrypting the P2P network doesn't resolve this problem, nor does authentication, nor does Tor. I would prefer we advance an actual solution to this significant problem than advance a false sense of security while creating both complexity and the likely evolution of node identity.

e