Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
Date: Thu, 30 Jun 2016 11:57:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@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>
	<CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


On Jun 29, 2016, at 3:01 AM, Gregory Maxwell <greg@xiph.org> wrote:
>=20
>> 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 a=
s its justifying scenario.
>=20
> It cites SPV as an example, doesn't mention bloom filters.. and sure-- sou=
nds like the bip text should make the

"MOTIVATION:
The Bitcoin network does not encrypt communication between peers today. This=
 opens up security issues (eg: traffic manipulation by others) and allows fo=
r mass surveillance / analysis of bitcoin users. Mostly this is negligible b=
ecause of the nature of Bitcoins trust model, however for SPV nodes this can=
 have significant privacy impacts [1] and could reduce the censorship-resist=
ance of a peer."

This is not an example, this is the exception that is described as "signific=
ant" in comparison to the other issues, which are described as "negligible".=


The Bloom filters messages are of course the unique aspects of the protocol a=
s it pertains to "SPV".

The RISKS section declares that the BIP cannot prevent MITM attacks and that=
 "identity authentication" will  be defined in a forthcoming BIP.

The obvious implication (accepted by the author) is that authentication is r=
equired to prevent a MITM attack, and furthermore establishment of identity w=
ill be required to ensure that the authenticated party is not a bad actor.

>>> Without something like BIP151 network participants cannot have privacy f=
or the transactions they originate within the protocol against network obser=
vers.
>>=20
>> And they won't get it with BIP151 either. Being a peer is easier than obs=
erving the network.
>=20
> Not passively, undetectable, and against thousands of users at once at low=
 cost.

This is a straw man, as the BIP does not state that its objective is to mode=
rately raise the cost of passive attack against large numbers of users.

It is also a red herring, as passivity is not itself a benefit. It implies t=
hat the attack is easier and therefore less costly. But a trivial active att=
ack may be a larger security problem than a complex passive attack. Attacks a=
gainst privacy under this BIP (and with authentication) can be carried out b=
y passively monitoring traffic and operating one or more nodes. Operating a n=
ode may be considered "active" because the node communicates, but technicall=
y it is not. In either case the activeness itself hardly raises the difficul=
ty, especially for a global (thousands of users) passive attacker.

Depending on the attacker, cost may not be an issue at all, so raising it ca=
n have zero effect. Certainly we are not talking about prohibitive (cryptogr=
aphically hard) cost. Raising the cost *any* amount is not likely a reasonab=
le cost-benefit tradeoff.

Privacy attacks would remain entirely undetectable under this proposal, and u=
nder any additional proposal that required authentication in the absence of i=
dentity. Only with all users of the network identified as "good" would such p=
roposals be effective. Until that point any bad actors can become an integra=
l part of the network. I will investigate the question of identity in a foll=
ow-up to an independent post.

>> If one can observe the encrypted traffic one can certainly use a timing a=
ttack to determine what the node has sent.
>=20
> 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)

It cannot be both impossible ("not against Bitcoin Core") and limited in eff=
ectiveness ("obviously there are limits").

We should be clear at this point that the transaction-posting security provi=
ded against a privacy attack, based on the assumption of "good" (identified)=
 peers in the first few hops, derives entirely from the ability of the good p=
eers to break the timing attack, which is itself "limited".

This is a compound pair of weak assumptions, that to be made stronger will r=
equire widespread use of identity (not just authentication).

The proliferation of node identity is my primary concern - this relates to p=
rivacy and the security of the network. Secondarily I am concerned about use=
rs operating under a false assumption about the strength of privacy. Thirdly=
 I am concerned about the risk of vulnerability introduced by the integratio=
n into the P2P network layer of an totally new network security scheme. Four=
thly I'm concerned about the cost of the above based on the belief that the b=
enefit may not be material and that it may lead to increased centralization.=


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

>>=20
>> 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 like=
 PKI?
>=20
> Huh? The first and subsequent hops obscures the origin and timing.

Described as "limited" in effectiveness, and clearly useful only if these ho=
ps are not attacker nodes.

So back to my comment on how we maintain a pool of "good" nodes for people t=
o connect to, and raising the question of how effective is this strategy (wh=
ich is itself unspecified and so cannot be assumed to even exist in the cont=
ext of the BIP).

>>> 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.
>>=20
>> If we trust the manual links we don't need/want the other links. In fact r=
etaining the other links enables the attack you described above. Of course t=
here is no need to worry about Sybil attacks when all of your peers are auth=
enticated. But again, let us not ignore the problems of requiring all peers o=
n the network be authenticated.
>=20
> 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 vulnerab=
ility-- so long as an active network attacker isn't
> intercepting all your connections out.

Don't want them as peers for the purpose of tx relay. As I said this, "enabl=
es the attack you described above."

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

This whitelisting is simply a stand-in for a more formal identity system. On=
e doesn't whitelist anonymous peers, one whitelists peers controlled by trus=
ted parties. Preferring trusted peers is another aspect of trying to break t=
he timing attack. So I would lump this under the same analysis as above (bat=
ching).

>> 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 i=
tself implements an identity scheme. I thought this was clear from the conte=
xt.
>=20
> I understood that, but my point was that Bitcoin cannot be used at all_unl=
ess users have secure communication channels to share addresses.

This is true but not relevant. The parties with whom we transact are not in t=
he same space as the nodes with which we connect. The fact that I am face-to=
-face with a counterparty does not help me find a "good" node, nor does my a=
bility to PGP email a payment address or to send a stealth address in the cl=
ear.

But the fact that you raise this point is itself instructive. The solution t=
hat was devised to resolve the problem of verifying that a counterparty is w=
ho one thinks it is ended up being based on the use of certificate authoriti=
es - despite the fact the the BIP did not require this. Some people consider=
 this extremely dangerous for Bitcoin, enough so that Peter Todd recently pr=
oposed scrapping the BIP.

It's not clear to me how the Bitcoin community intends to establish what nod=
es are good nodes. But one thing is certain, any anonymous node may be an un=
detectable attacker.

>> then there is no reason to expect any effective improvement, since nodes w=
ill necessarily have to connect with anonymous peers.
>=20
> They're not required to _only_ connect with anonymous peers. And partition=
 resistance requires that you have any one good link.

As a minimum requirement, it implies that only need only to connect to one o=
r more "good" peers. Anonymous peers are gravy for partition resistance, yet=
 they are potential attackers for tx tainting. In other words the logical to=
pology is to only connect to good peers. That is a problem.

>> Anyone with a node and the ability to monitor traffic should remain very e=
ffective.
>=20
> Not via passive observation.

See above commentary on the irrelevance of this distinction.

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

I don't get your point here. It seems like you are just trying to antagonize=
.

> We seem to be looping now. Feel free to not implement this proposal,

At this point I think it's fair for me to say that nobody needs your permiss=
ion.

> no one suggests making it mandatory.

Have you ever debated an optional feature proposal?

e=