path: root/be/dc3a0a35816559ba0361b45c3a482ed2a07fc1

Return-Path: <bastien.teinturier@acinq.fr>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BB589C016E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 20 Jun 2020 08:54:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id B45DD203C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 20 Jun 2020 08:54:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id RjsVRQV5VWqf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 20 Jun 2020 08:54:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
 [209.85.210.43])
 by silver.osuosl.org (Postfix) with ESMTPS id C6FD9207EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 20 Jun 2020 08:54:15 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id n6so9199599otl.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 20 Jun 2020 01:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=6girSHmLja6xDNrUsnbs/3btlt85cEWk4uzv4074n6M=;
 b=qSa91oyupwa4UM5H23duumK8/UAlkEKXRH59KtK3gQPv0Ed55aiOb7c+JYlysVrMB/
 labFKj1Ur2oT9n7ykkOF9ilj2NoYOch01KgUlyXyd4JmZmsYaFD88TdE3mTivu62jmLd
 Q7PJJirTuiuGGuPzz9Q8SBTJSdyzWXk3bhQ2K++k11U6cUq0f+u6LR7yj9Cdo/lM8g5n
 X7mQJd3GXqFt7nV8DLdyk9XnMRpgpF/DBFI5aL8C2hr8OwmZS1ajJttth4CMPOHdbvbk
 PP9vosDj5/xGL1o+s4LkgEoDs4vzQHch5yJ5QwjT1opZf1sKl8URtIlSbtKogf9aOU/s
 oSog==
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:cc;
 bh=6girSHmLja6xDNrUsnbs/3btlt85cEWk4uzv4074n6M=;
 b=jF6oBb0KaEWaTkjI8EWj7UT7VBbgcVeomvew5Qs3II+4fxIQOXCDPmbrA4MqM4DAU1
 YlrtG78oGOdvSyWBsQSedg3spskUr/f3+AvUw8x97A/rXahMIcwqu/MMnd3EfqKqeRxZ
 gRycPUkNReELQZwTVMJ+6/iDIKRZrTVY6Wb8uE7wfJI9qrSbUYu4tC2Pw2A9Dxza2uTV
 g1NrtkoJPv1c3n70cVqax3Lrg2ElDOMny/fbQARm2fQmZEibb1un9zEhmyK34l3VMoqU
 cou9I8RqMmLHMwoFhFsUdR0ZgXLLLURhtWqRmCBv4w2fJdWpLH4s6EXDRamMg8VodaPp
 YQSg==
X-Gm-Message-State: AOAM531G5cCPwQ9ESuNNDxwaIzz/I2mYcFA9QLhMSsyp1fu4x29eOhYl
 /DAgTafcI5iHHTx4vLyapG5TCqCIPm9YgyczTKAgE5wmYeM=
X-Google-Smtp-Source: ABdhPJwwoQQ1M6l64vqLeF1OECuJdzG8nF/MVbf96qqc4FntGk5mmmxEcWSHPhtKDyepOd3R6Ra4ZrXeyavpSJr54m8=
X-Received: by 2002:a9d:2ae3:: with SMTP id e90mr6434324otb.261.1592643254841; 
 Sat, 20 Jun 2020 01:54:14 -0700 (PDT)
MIME-Version: 1.0
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
 <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
 <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
 <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
 <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
 <20200619195846.fclw4ilngvbbf2kk@ganymede>
 <20200619205220.fshbr7pbijaerbf2@ganymede>
In-Reply-To: <20200619205220.fshbr7pbijaerbf2@ganymede>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Sat, 20 Jun 2020 10:54:03 +0200
Message-ID: <CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="00000000000075847305a8802785"
X-Mailman-Approved-At: Sat, 20 Jun 2020 09:11:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
 and Competing Interest
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 20 Jun 2020 08:54:18 -0000

--00000000000075847305a8802785
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dave and list,

Thanks for your quick answers!

The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>

Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim the revocation paths when seeing the transaction in a
block and get all the
channel funds (since the attacker's outputs will be CSV-locked).

The only way your Bitcoin peer will relay your blind child
> is if it already has the parent transaction.
>

That's an excellent point that I missed in the blind CPFP carve-out trick!
I think this makes the
blind CPFP carve-out quite hard in practice (even using getdata - thanks
for detailing that option)...

In the worst case scenario where most miners' mempools contain the
attacker's tx and the rest of
the network's mempools contains the honest participant's tx, I think there
isn't much we can do.
We're simply missing information, so it looks like the only good solution
is to avoid being in that
situation by having a foot in miners' mempools. Do you think it's
unreasonable to expect at least
some LN nodes to also invest in running nodes in mining pools, ensuring
that they learn about
attackers' txs and can potentially share discovered preimages with the
network off-chain (by
gossiping preimages found in the mempool over LN)? I think that these
recent attacks show that
we need (at least some) off-chain nodes to be somewhat heavily invested in
on-chain operations
(layers can't be fully decoupled with the current security assumptions -
maybe Eltoo will help
change that in the future?).

Thank you for your time!
Bastien



Le ven. 19 juin 2020 =C3=A0 22:53, David A. Harding <dave@dtrt.org> a =C3=
=A9crit :

> On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-de=
v
> wrote:
> > I think you're assuming here that the attacker broadcast a particular
> > state.
>
> Whoops, I managed to confuse myself despite looking at Bastien's
> excellent explainer.  The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.  However, the blind child will only be relayed by a Bitcoin peer
> if the peer also has the parent transaction (the latest state) and, if
> it has the parent transaction, you should be able to just getdata('tx',
> $txid) that transaction from the peer without CPFPing anything.  That
> will give you the preimage and so you can immediately resolve the HTLC
> with the upstream channel.
>
> Revising my conclusion from the previous post:
>
> I think the strongman argument for the attack would be that the attacker
> will be able to perform a targeted relay of the low-feerate
> preimage-containing transaction to just miners---everyone else on the
> network will receive the honest user's higher-feerate expired-timelock
> transaction.  Unless the honest user happens to have a connection to a
> miner's node, the user will neither be able to CPFP fee bump nor use
> getdata to retrieve the preimage.
>
> Sorry for the confusion.
>
> -Dave
>

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

<div dir=3D"ltr">Hello Dave and list,<div><br></div><div>Thanks for your qu=
ick answers!</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">The attacker would be broadcasting the latest<br>state, so the hone=
st counterparty would only need to send one blind<br>child.<br></blockquote=
><div><br></div><div>Exactly, if the attacker submits an=C2=A0outdated tran=
saction he would be shooting himself in the foot,</div><div>as we could cla=
im the revocation paths when seeing the transaction in a block and get all =
the</div><div>channel funds (since the attacker&#39;s outputs will be CSV-l=
ocked).</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">The only way your Bitcoin peer will relay your blind child<br>is if it a=
lready has the parent transaction.<br></blockquote><div><br></div><div>That=
&#39;s an excellent point that I missed in the blind CPFP carve-out trick! =
I think this makes the</div><div>blind CPFP carve-out quite hard in practic=
e (even using getdata - thanks for detailing that option)...</div><div><br>=
</div><div>In the worst case scenario where most miners&#39; mempools conta=
in the attacker&#39;s tx and the rest of</div><div>the network&#39;s mempoo=
ls contains the honest participant&#39;s tx, I think there isn&#39;t much w=
e can do.</div><div>We&#39;re simply missing information, so it looks like =
the only good solution is to avoid being in that</div><div>situation by hav=
ing a foot in miners&#39; mempools. Do you think it&#39;s unreasonable to e=
xpect at least</div><div>some LN nodes to also invest in running nodes in m=
ining pools, ensuring that they learn about</div><div>attackers&#39; txs an=
d can potentially share discovered preimages with the network off-chain (by=
</div><div>gossiping preimages found in the mempool over LN)? I think that =
these recent attacks show that</div><div>we need (at least some) off-chain =
nodes to be somewhat heavily invested in on-chain operations</div><div>(lay=
ers can&#39;t be fully decoupled with the current security assumptions - ma=
ybe Eltoo will help</div><div>change that in the future?).</div><div><br></=
div><div>Thank you for your time!</div><div>Bastien</div><div><br></div><di=
v><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">Le=C2=A0ven. 19 juin 2020 =C3=A0=C2=A022:53, David A. Harding &=
lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun=
 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:<br>
&gt; I think you&#39;re assuming here that the attacker broadcast a particu=
lar<br>
&gt; state.=C2=A0 <br>
<br>
Whoops, I managed to confuse myself despite looking at Bastien&#39;s<br>
excellent explainer.=C2=A0 The attacker would be broadcasting the latest<br=
>
state, so the honest counterparty would only need to send one blind<br>
child.=C2=A0 However, the blind child will only be relayed by a Bitcoin pee=
r<br>
if the peer also has the parent transaction (the latest state) and, if<br>
it has the parent transaction, you should be able to just getdata(&#39;tx&#=
39;,<br>
$txid) that transaction from the peer without CPFPing anything.=C2=A0 That<=
br>
will give you the preimage and so you can immediately resolve the HTLC<br>
with the upstream channel.<br>
<br>
Revising my conclusion from the previous post:<br>
<br>
I think the strongman argument for the attack would be that the attacker<br=
>
will be able to perform a targeted relay of the low-feerate<br>
preimage-containing transaction to just miners---everyone else on the<br>
network will receive the honest user&#39;s higher-feerate expired-timelock<=
br>
transaction.=C2=A0 Unless the honest user happens to have a connection to a=
<br>
miner&#39;s node, the user will neither be able to CPFP fee bump nor use<br=
>
getdata to retrieve the preimage.<br>
<br>
Sorry for the confusion.<br>
<br>
-Dave<br>
</blockquote></div>

--00000000000075847305a8802785--