path: root/aa/59f418605ba16b5dd1b65129eee172f9b42109

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A96FD26C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 09:57:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com
	[209.85.192.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2276196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 09:57:07 +0000 (UTC)
Received: by mail-pf0-f169.google.com with SMTP id h14so27939269pfe.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jun 2016 02:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=rwjN3JTNpKIJYTo1Ldtqn0xjs4CWFC8XWLAVkC7g288=;
	b=K8NIhn+6MqmrRZRJ6TkOVesNJasuaCBxCgVJSP3ZD0HiPLqiHg6QJQBNOdpQB1G+ZH
	d1QHoqB+QiuBTgZRLwcTlinWZt4svZwdN94KjdO2R8twMs/yGNSemwnD5/rDeTR4aSWL
	s7O8nCdgE/PKvia5pQTrYh70ktVHemOw06I2WFNlgA69+Nvi/OFrRRNhTn4r+XpcNceV
	YF2xT7tfPbMBHXEqpiAFN+B5ur/BMcsPrRid1pl+3oYglbMtwNS0FUu8Gy7glRqxivfl
	nQJ632ENDm/3hsDSHp0cQzpN63MDwTTG90d5Smoyfi4QksY1m9DDLbiWHl1+QPAteS2a
	5B2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=rwjN3JTNpKIJYTo1Ldtqn0xjs4CWFC8XWLAVkC7g288=;
	b=WUqgB6PmuiPxaQNWrbNIKnH8xIp9vY5Mv0XMn8Av/B0GSk3nvJMLa04xGz07/PNLc+
	9VBJU68p2JJjcu0+Pdm2LDMeP8vVaLghLpAGzCTzflFomHzqdAwN1PTyiSJtZJ5McgtA
	/Oq1J80q8FX22HSjmaFJjHFtgu1jGLsp6vejdwebTiIs6VjXsbph6aQe4arGIIkz59nf
	SM2Q+9lQ+ABygKxV1zKW3qA3yPpFDWE88M55o21AN2hwECszKIZJQno6/OiB+JSVxSHY
	yPZmC0+UwaujuFH22cctbKndF4a1DUi/QkvFUIJVJ7KvcFeD8AKr3gbhrbBjaj0Bxn6n
	bMnA==
X-Gm-Message-State: ALyK8tIW6wwmP6lMpIzu76jSiU0FZyyCYkcsLy/XyP5oA25exUNWo1VksVbh7FTRzaGKjw==
X-Received: by 10.98.102.66 with SMTP id a63mr19769419pfc.32.1467280627495;
	Thu, 30 Jun 2016 02:57:07 -0700 (PDT)
Received: from [10.171.23.222] ([166.170.43.16])
	by smtp.gmail.com with ESMTPSA id 75sm4194038pfy.32.2016.06.30.02.57.05
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Thu, 30 Jun 2016 02:57:06 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
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>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 09:57:11 -0000


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=