Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
Date: Wed, 29 Jun 2016 01:34:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D317F7C9-C645-455F-8BA6-EB9F6D09F39F@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
	<20160628182202.GA5519@fedora-21-dvm>
	<D40F9E9D-DB6C-4083-A9E8-C5EBC363DB30@voskuil.org>
	<20160628201447.GA1148@fedora-21-dvm>
	<4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org>
	<20160628203605.GA1328@fedora-21-dvm>
	<E8335291-7142-4E21-A1E2-76F387426741@voskuil.org>
	<CAAS2fgRGbnH-NtPRdLe0yhFSoqJ7b6O25LfyGv_ULHhy8bBSpg@mail.gmail.com>
	<7F95A7F5-848C-4EA6-9503-C48F45AC1C34@voskuil.org>
	<CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:=

>>=20
>> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil <eric@voskuil.org> wrote:
>> Passing the session ID out of band is authentication. As this is explicit=
ly not part of BIP151 it cannot be that BIP151 provides the tools to detect a=
 attack (the point at issue).
>=20
> 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.
>=20
>>>> It requires a secure channel and is authentication. So BIP151 doesn't p=
rovide the tools to detect an attack, that requires authentication. A genera=
l requirement for authentication is the issue I have raised.
>>>=20
>>> One might wonder how you ever use a Bitcoin address, or even why we migh=
t guess these emails from "you" aren't actually coming from the NSA.
>>=20
>> The sarcasm is counterproductive Greg. By the same token I could ask how y=
ou ever use Bitcoin given that the P2P protocol is not encrypted or authenti=
cated.
>=20
> I think I was unclear. A bitcoin address needs to be sent over a secure ch=
annel, which we do not provide. Yet sending funds to addresses instead of an=
yone_can_spend is pretty useful.
>=20
> 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 f=
act tampered messages might be detected is a big disincentive from trying.

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

>> The blockchain and mempool are a cache of public data. Transmission of a p=
ayment address to a payer is not a comparable scenario.
>=20
> 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 arriv=
ing at an arbitrary node, including the order of arrival, is by definition p=
ublic information. The only possible way it could be considered private is i=
f 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 n=
ot possible without centralized access control.

Encrypting the P2P network doesn't resolve this problem, nor does authentica=
tion, nor does Tor. I would prefer we advance an actual solution to this sig=
nificant problem than advance a false sense of security while creating both c=
omplexity and the likely evolution of node identity.

e=