MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
	<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 29 Jun 2016 01:01:50 +0000
Message-ID: <CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org> wrote:
> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets =
as its justifying scenario.

It cites SPV as an example, doesn't mention bloom filters.. and sure--
sounds like the bip text should make the

>> Without something like BIP151 network participants cannot have privacy f=
or the transactions they originate within the protocol against network obse=
rvers.
>
> And they won't get it with BIP151 either. Being a peer is easier than obs=
erving the network.

Not passively, undetectable, and against thousands of users at once at low =
cost.

> If one can observe the encrypted traffic one can certainly use a timing a=
ttack to determine what the node has sent.

Not against Bitcoin Core, transactions are batched and relayed in
sorted order.  (obviously there are limits at what this provides;
ironically, the lack of link encryption has been used to argue against
privacy preserving relay behavior)

>> Even if, through some extraordinary effort, their own first hop is encry=
pted, 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 authentic=
ated, and all participants are known to be good guys. Starting to sound lik=
e PKI?

Huh? The first and subsequent hops obscures the origin and timing.

>> 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 a=
uthenticated. But again, let us not ignore the problems of requiring all pe=
ers on the network be authenticated.

Don't need and want them for what?  For _partitioning_ resistance,
you are not partitioned if you have one honest connection to the
functional network. Additional peers purely reduce your partition
vulnerability-- so long as an active network attacker isn't
itercepting all your connections out.

For privacy, you have improve transaction privacy so long as your
transaction isn't initially relayed to a malicious peer-- but
malicious peers can lie further out because transit nodes obscure the
order of message creation.  Bitcoin Core currently relays transactions
first and more frequently to outbound and whitelisted peers.

> 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 con=
text.

I understood that, but my point was that Bitcoin cannot be used at
all_unless users have secure communication channels to share
addresses.

> then there is no reason to expect any effective improvement, since nodes =
will necessarily have to connect with anonymous peers.

They're not required to _only_ connect with anonymous peers. And
partition resistance requires that you have any one good link.

> Anyone with a node and the ability to monitor traffic should remain very =
effective.

Not via passive observation.

> Defining an auth implementation is not a hard problem, nor is it the conc=
ern I have raised.

Glad you agree.

We seem to be looping now. Feel free to not implement this proposal,
no one suggests making it mandatory.