path: root/de/fd552ef74b978238d82b40560d77977d69dfc9

Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 97D8515DA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Jun 2018 01:05:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com
	[74.125.82.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0BEEEC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Jun 2018 01:05:31 +0000 (UTC)
Received: by mail-ot0-f180.google.com with SMTP id a5-v6so26099140otf.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Jun 2018 18:05:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=sEO/8M+k4FyDsCkhAkzmHDVEJ86xJmPUTFSmVd95qvI=;
	b=T7CN0of0YO6s6+MEltyi5uZFSiv4HcNnxeLLWY4zPnseXtrss8KDlNt0RxeZH7tpDX
	3IqJBxEbJf+Zqro5FckMcTTOYoYA0IzVVtfuqyiRqOZHoGm6UgYES8wAj8gDObdMb2/o
	1tb58akqMWhE1C+DRvFHeA353R633wFUm9/tDDvpzMtHOoOTA7bBLv7Ah/b6LkWSs0gt
	LGbhZbLwjKcmrD0fLyPgpAEYyud4jjfUOOcGVkMe2rp9Ih0oZnP/we1ZwdZNfgRVNKdj
	c16lC9feuRBy2J+VPQ1FfhUluGf1yVTgJ50IEPJOS5xyQ1/0v8Ea3r+WEidCYYxriFKH
	QH7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=sEO/8M+k4FyDsCkhAkzmHDVEJ86xJmPUTFSmVd95qvI=;
	b=W9G+NILGvHWHBknBQjg3XuFPY4WpbAgyYEi7Lw6tpsxQu5c2VVE7x8Gjfr8/zwHwx0
	0FEhl+2wOxjR5lQVV2XZG139TnMCXwdVDG0Xvb3en7+9+zCzp6i72sNm8/wrOKTI7yKJ
	ygJPGXipsc/DRpNrRVhSpRTS7GQvcsPHi3Xbb916kWB3KbsR8Y/LnOl4wAlFrbJT+6KP
	QC7pM5gC9QoUl11Mn3vrv0Z37VM0SWnh+V97ephEdRglY77elX/sitEUT4svv5TGqAvv
	y7WukGHp6GYjBPgaYnueJRFyfxCs5QLCK5ROAb1a3qfDWD8QU2FLZrzXZGoTR+mc8vIK
	B6hA==
X-Gm-Message-State: APt69E0YJWU6TXNQAewrVnnlCqGpsw5pmQEXropmAiYnmPke3xsnrnHV
	gLrgPjGgW/QYjD1viAjryfSycec+jPrFNeqYDZs=
X-Google-Smtp-Source: ADUXVKIXUrXNntkwR2/giRpNHV6bqB47LGM8W3u7Rz9dNvMiKaZJiGWUUP9z7ikIO13JnxK5oBi4sKe2TZnxGZ3AcO0=
X-Received: by 2002:a9d:3d76:: with SMTP id
	a109-v6mr1072245otc.294.1528765530683; 
	Mon, 11 Jun 2018 18:05:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAGq_bNLvnZcOGU7c-8i7OL-OGAp4N2bX9T5SEROm59YBGL5yzw@mail.gmail.com>
	<CAPg+sBjdTmZ4m5c92CQK5DsU18M=GKgTM-OZZzwgjpE3hqe6=w@mail.gmail.com>
	<CAGq_bNKj4rA9pzk7CPA0r099PXOy3naNfZsr=MSPpYh08OZ6TQ@mail.gmail.com>
In-Reply-To: <CAGq_bNKj4rA9pzk7CPA0r099PXOy3naNfZsr=MSPpYh08OZ6TQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 11 Jun 2018 18:05:14 -0700
Message-ID: <CAPg+sBj7HoR8ptaZw9UeJYDegk2q6y0w9s8tOg6mc2bzNw4zVw@mail.gmail.com>
To: Bradley Denby <bdenby@cmu.edu>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000066bf5c056e677688"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving
 Transaction Propagation
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: Tue, 12 Jun 2018 01:05:32 -0000

--00000000000066bf5c056e677688
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks for the comments Pieter!
>
> We can make descriptions for the intended node behaviors more clear in the
> BIP.
>
> Regarding interaction with BIPs 37 and 133, we have found that if
> Dandelion routing decisions are based on self-reported features, malicious
> nodes can often exploit that to launch serious deanonymization attacks. As
> a result, we recommend not allowing fee filters from peers to influence the
> choice of route. Your suggestion of automatically fluffing is a good
> solution. Another (similar) option would be to apply fee filters in the
> stempool. This would prevent the tx from propagating in stem phase, so
> eventually an embargo timer on the stem will expire and the transaction
> will fluff. This is slower than auto-fluffing, but requires (slightly) less
> code.
>

I understand the argument about not making routing decisions based on
self-reported features, but I would expect it to only matter if done
selectively? Allowing a node to opt out of Dandelion entirely should always
be possible regardless - as they can always indicate not supporting it.

The reason for my suggestion was that most full nodes on the network use
feefilter, while only (from the perspective of Dandelion uninteresting)
light nodes and blocksonly nodes generally use Bloom filters.

Just dropping stem transactions that would otherwise be sent to a Dandelion
peer which fails its filter, and relying on embargo seems fine. But perhaps
this option is something to describe in the BIP ("Nodes MAY choose to
either drop stem transactions or immediately start diffusion when a
transaction would otherwise be sent to a Dandelion node whose filter is not
satisfied for that transaction. A node SHOULD NOT make any routing
decisions based on the transaction itself, and thus SHOULD NOT try to find
an alternative Dandelion node to forward to" for example).

Regarding mempool-dependent transactions, the reference implementation adds
> any mempool transactions to the stempool but not vice-versa so that the
> stempool becomes a superset of the mempool. In other words, information is
> free to flow from the mempool to the stempool. Information does not flow
> from the stempool to the mempool except when a transaction fluffs. As a
> result, a node's stempool should accept and propagate Dandelion
> transactions that depend on other unconfirmed normal mempool transactions.
> The behavior you described is not intended; if you have any tests
> demonstrating this behavior, would you mind sharing them?
>

Oh, I see! I was just judging based on the spec code you published, but I
must have missed this. Yes, that makes perfect sense. There may be some
issues with this having a significant impact on stempool memory usage, but
let's discuss this later on implementation.

Orphans: stem orphans can occur when a node on the stem shuffles its route
> between sending dependent transactions. One way to deal with this issue
> would be to re-broadcast all previous Dandelion transactions that have not
> been fluffed after Dandelion route shuffling. This could add a fair amount
> of data and logic. This re-broadcast method also telegraphs the fact that a
> Dandelion shuffle has taken place and can result in bursts of transactions
> depending on traffic patterns. A second option (which we used in the
> reference implementation) is to wait for the fluff phase to begin, at which
> point the orphans will be resolved. This should happen within 15 seconds
> for most transactions. Do you have any thoughts on which option would be
> more palatable? Or if there are other options we have missed?
>

Another option (just brainstorming, I may be missing something here), is to
remember which peer each stempool transaction was forwarded to. When a
dependent stem transaction arrives, it is always sent to (one of?) the
peers its dependencies were sent to, even if a reshuffle happened in
between.

Thinking more about it, relying on embargo is probably fine - it'll just
result in slightly lowered average stem length, and perhaps multiple
simultaneous fluffs starting?

Regarding preferred connections, we have found that making Dandelion
> routing decisions based on claims made by peer nodes can cause problems and
> therefore would recommend against biasing the peer selection code.
>

Oh, I don't mean routing decisions, but connections in general.

On the implementation side:
>

Let's discuss these later.


> Based on the feedback we have received so far, we are planning to
> prioritize writing up a clearer spec for node behavior in the BIP. Does
> that seem reasonable, or are there other issues that are more pressing at
> this point?
>

I think that's the primary thing to focus on at this point, but perhaps
others on this list feel different.

Cheers,

-- 
Pieter

--00000000000066bf5c056e677688
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, =
Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Thanks for the comments Pieter!</div><div><br></div><div>We can make descr=
iptions for the intended node behaviors more clear in the BIP.</div><div><b=
r></div><div>Regarding interaction with BIPs 37 and 133, we have found that=
 if Dandelion routing decisions are based on self-reported features, malici=
ous nodes can often exploit that to launch serious deanonymization attacks.=
 As a result, we recommend not allowing fee filters from peers to influence=
 the choice of route. Your suggestion of automatically fluffing is a good s=
olution. Another (similar) option would be to apply fee filters in the stem=
pool. This would prevent the tx from propagating in stem phase, so eventual=
ly an embargo timer on the stem will expire and the transaction will fluff.=
 This is slower than auto-fluffing, but requires (slightly) less code.</div=
></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">I understand the argument about not making routing decisions based on se=
lf-reported features, but I would expect it to only matter if done selectiv=
ely? Allowing a node to opt out of Dandelion entirely should always be poss=
ible regardless - as they can always indicate not supporting it.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">The reason for my suggestion was t=
hat most full nodes on the network use feefilter, while only (from the pers=
pective of Dandelion uninteresting) light nodes and blocksonly nodes genera=
lly use Bloom filters.</div><div dir=3D"auto"><br></div><div dir=3D"auto">J=
ust dropping stem transactions that would otherwise be sent to a Dandelion =
peer which fails its filter, and relying on embargo seems fine. But perhaps=
 this option is something to describe in the BIP (&quot;Nodes MAY choose to=
 either drop stem transactions or immediately start diffusion when a transa=
ction would otherwise be sent to a Dandelion node whose filter is not satis=
fied for that transaction. A node SHOULD NOT make any routing decisions bas=
ed on the transaction itself, and thus SHOULD NOT try to find an alternativ=
e Dandelion node to forward to&quot; for example).</div><div dir=3D"auto"><=
br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Regarding mempool-dependent transactions, t=
he reference implementation adds any mempool transactions to the stempool b=
ut not vice-versa so that the stempool becomes a superset of the mempool. I=
n other words, information is free to flow from the mempool to the stempool=
. Information does not flow from the stempool to the mempool except when a =
transaction fluffs. As a result, a node&#39;s stempool should accept and pr=
opagate Dandelion transactions that depend on other unconfirmed normal memp=
ool transactions. The behavior you described is not intended; if you have a=
ny tests demonstrating this behavior, would you mind sharing them?</div></d=
iv></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">O=
h, I see! I was just judging based on the spec code you published, but I mu=
st have missed this. Yes, that makes perfect sense. There may be some issue=
s with this having a significant impact on stempool memory usage, but let&#=
39;s discuss this later on implementation.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Orphans: stem orphans can occur when a node on the =
stem shuffles its route between sending dependent transactions. One way to =
deal with this issue would be to re-broadcast all previous Dandelion transa=
ctions that have not been fluffed after Dandelion route shuffling. This cou=
ld add a fair amount of data and logic. This re-broadcast method also teleg=
raphs the fact that a Dandelion shuffle has taken place and can result in b=
ursts of transactions depending on traffic patterns. A second option (which=
 we used in the reference implementation) is to wait for the fluff phase to=
 begin, at which point the orphans will be resolved. This should happen wit=
hin 15 seconds for most transactions. Do you have any thoughts on which opt=
ion would be more palatable? Or if there are other options we have missed?<=
/div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Another option (just brainstorming, I may be missing something here)=
, is to remember which peer each stempool transaction was forwarded to. Whe=
n a dependent stem transaction arrives, it is always sent to (one of?) the =
peers its dependencies were sent to, even if a reshuffle happened in betwee=
n.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thinking more about i=
t, relying on embargo is probably fine - it&#39;ll just result in slightly =
lowered average stem length, and perhaps multiple simultaneous fluffs start=
ing?</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Regarding pref=
erred connections, we have found that making Dandelion routing decisions ba=
sed on claims made by peer nodes can cause problems and therefore would rec=
ommend against biasing the peer selection code.</div></div></blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">Oh, I don&#39;t mean=
 routing decisions, but connections in general.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>On the implementation side:</div><div></div></=
div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Let&#39;s discuss these later.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>Based on the feedback we have received so far,=
 we are planning to prioritize writing up a clearer spec for node behavior =
in the BIP. Does that seem reasonable, or are there other issues that are m=
ore pressing at this point?=C2=A0</div></div></blockquote></div></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">I think that&#39;s the primary thi=
ng to focus on at this point, but perhaps others on this list feel differen=
t.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">--=C2=A0</div><div dir=3D"auto">Piete=
r</div><div dir=3D"auto"><br></div></div>

--00000000000066bf5c056e677688--