path: root/e5/a922c0cd71b1d80aa40eef70b56021bada8676

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 D1912C016E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Jun 2020 07:44:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id BC2AD207A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Jun 2020 07:44:24 +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 ZpqRZzDNvwbq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Jun 2020 07:44:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com
 [209.85.210.48])
 by silver.osuosl.org (Postfix) with ESMTPS id 869CC204E5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Jun 2020 07:44:23 +0000 (UTC)
Received: by mail-ot1-f48.google.com with SMTP id g5so6607644otg.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 19 Jun 2020 00:44:23 -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;
 bh=rzsWHP+s6ec7vscYSALwXP21loT/cFjFXdez0bvKudU=;
 b=v6135i0qo3zbbqTkz/G+6+u2wl+pSY1mBA7lPNGtIQrJWjbyKpvhCtfwlmHG4d9R05
 Ie0GxK3BXFmPY874ivS399o2QSx7JPNQHb0PGlKmmTjpHFzMYrjmYvPvo0I7ayrK2sNn
 opiizxMgQhGR8oIKSdt6QB0RL4Trp/L/jxKpfhngHGwynu36b52h39JurLnfpFb4ApFQ
 ig6dtqLxnQHYUpsQvLhfn7MCJq6tiMGsa4rAFd6qwvYaQy4KPSG5wVFJJesmGC8BdGVq
 D0VWoUjqUWyltoR1AieoiqBOr2sy3aBR9X0qa+G17AzV4uaXolr3OvymXqP9rYF7l8lU
 GnTA==
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=rzsWHP+s6ec7vscYSALwXP21loT/cFjFXdez0bvKudU=;
 b=MW2/F6FezJ2DRr9Zvzv6Hsba7zjG7abqf81DZplBzf4TGBdKqOP8penb58tPrG3eMO
 3d5McqfW/rYkw4LJ6XC50MjXKIIJFveV6X7swshW4Qkjkg3zAJU2tnlpwkfE3G777guQ
 bXv7g9P9/0bkbSPo7qsx6VXEmTd11vGn3V5zuhlkI8gUDSymO96rJyyZK2u+9S9vQXL+
 zYuBQUf/HGU5fnwUw6y8Y6iS/JYp3JvUVT1rhIPL8NlrL0MEIIEMbCdpOnPkMhcqLcni
 Aeo+HcLiZjONgNAwDLGWo3ldexfwUm8ZVL5tIW7cHySlYROs+Q8M0hgbgWjQCWzHkomE
 K94g==
X-Gm-Message-State: AOAM530OXWyQYWrpYKPDhyFv49fUB8SRJGziNnd1gG3zzCoEpwjGxTbd
 VzmmViKhee6j82nMTIcsHoD8gCJkZkwTNH8uEmcWUw==
X-Google-Smtp-Source: ABdhPJzLkk7h8ZEqtNXyykgqUfpC3x3iFJEy10viN7A7FKnGPoYjfA1Tb4oWCG446eFHNLWxymz9W+5Lor7zjS7pGjo=
X-Received: by 2002:a05:6830:22f1:: with SMTP id
 t17mr2061874otc.288.1592552662495; 
 Fri, 19 Jun 2020 00:44:22 -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>
In-Reply-To: <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Fri, 19 Jun 2020 09:44:11 +0200
Message-ID: <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bc075605a86b0fbc"
X-Mailman-Approved-At: Fri, 19 Jun 2020 08:00:22 +0000
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: Fri, 19 Jun 2020 07:44:24 -0000

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

Good morning list,

Sorry for being (very) late to the party on that subject, but better late
than never.

A lot of ideas have been thrown at the problem and are scattered across
emails, IRC discussions,
and github issues. I've spent some time putting it all together in one
gist, hoping that it will
help stir the discussion forward as well as give newcomers all the
background they need to ramp up
on this issue and join the discussion, bringing new ideas to the table.

The gist is here, and I'd appreciate your feedback if I have wrongly
interpreted some of the ideas:
https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12

Readers of this list can probably directly skip to the "Future work"
section. I believe my
"alternative proposal" should loosely reflect Matt's proposal from the very
first mail of this
thread; note that I included anchors and new txs only in some places, as I
think they aren't
necessary everywhere.

My current state-of-mind (subject to change as I discover more potential
attacks) is that:

* The proposal to add more anchors and pre-signed txs adds non-negligible
complexity and hurts
small HTLCs, so it would be better if we didn't need it
* The blind CPFP carve-out trick is a one shot, so you'll likely need to
pay a lot of fees for it
to work which still makes you lose money in case an attacker targets you
(but the money goes to
miners, not to the attacker - unless he is the miner). It's potentially
hard to estimate what fee
you should put into that blind CPFP carve-out because you have no idea what
the current fee of the
pinned success transaction package is, so it's unsure if that solution will
really work in practice
* If we take a step back, the only attack we need to protect against is an
attacker pinning a
preimage transaction while preventing us from learning that preimage for at
least `N` blocks
(see the gist for the complete explanation). Please correct me if that
claim is incorrect as it
will invalidate my conclusion! Thus if we have:
* a high enough `cltv_expiry_delta`
* [off-chain preimage broadcast](
https://github.com/lightningnetwork/lightning-rfc/issues/783)
(or David's proposal to do it by sending txs that can be redeemed via only
the preimage)
* LN hubs (or any party commercially investing in running a lightning node)
participating in
various mining pools to help discover preimages
* decent mitigations for eclipse attacks
* then the official anchor outputs proposal should be safe enough and is
much simpler?

Thank you for reading, I hope the work I put into this gist will be useful
for some of you.

Bastien

Le ven. 24 avr. 2020 =C3=A0 00:47, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

>
>
> On 4/23/20 8:46 AM, ZmnSCPxj wrote:
> >>> -   Miners, being economically rational, accept this proposal and
> include this in a block.
> >>>
> >>> The proposal by Matt is then:
> >>>
> >>> -   The hashlock branch should instead be:
> >>> -   B and C must agree, and show the preimage of some hash H (hashloc=
k
> branch).
> >>> -   Then B and C agree that B provides a signature spending the
> hashlock branch, to a transaction with the outputs:
> >>> -   Normal payment to C.
> >>> -   Hook output to B, which B can use to CPFP this transaction.
> >>> -   Hook output to C, which C can use to CPFP this transaction.
> >>> -   B can still (somehow) not maintain a mempool, by:
> >>> -   B broadcasts its timelock transaction.
> >>> -   B tries to CPFP the above hashlock transaction.
> >>> -   If CPFP succeeds, it means the above hashlock transaction exists
> and B queries the peer for this transaction, extracting the preimage and
> claiming the A->B HTLC.
> >>
> >> Note that no query is required. The problem has been solved and the
> preimage-containing transaction should now confirm just fine.
> >
> > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a
> block.
> >
> > Even if C hooks a tree of low-fee transactions on its hook output or
> normal payment, miners will still be willing to confirm this and the B ho=
ok
> CPFP transaction without, right?
>
> Correct, once it makes it into the mempool we can CPFP it and all the
> regular sub-package CPFP calculation will pick it
> and its descendants up. Of course this relies on it not spending any othe=
r
> unconfirmed inputs.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Good morning list,<br><br>Sorry for being (very) late to t=
he party on that subject, but better late than never.<br><br>A lot of ideas=
 have been thrown at the problem and are scattered across emails, IRC discu=
ssions,<br>and github issues. I&#39;ve spent some time putting it all toget=
her in one gist, hoping that it will<br>help stir the discussion forward as=
 well as give newcomers all the background they need to ramp up<br>on this =
issue and join the discussion, bringing new ideas to the table.<br><br>The =
gist is here, and I&#39;d appreciate your feedback if I have wrongly interp=
reted some of the ideas:<br><a href=3D"https://gist.github.com/t-bast/22320=
336e0816ca5578fdca4ad824d12">https://gist.github.com/t-bast/22320336e0816ca=
5578fdca4ad824d12</a><div><br>Readers of this list can probably directly sk=
ip to the &quot;Future work&quot; section. I believe my<br>&quot;alternativ=
e proposal&quot; should loosely reflect Matt&#39;s proposal from the very f=
irst mail of this<br>thread; note that I included anchors and new txs only =
in some places, as I think they aren&#39;t<br>necessary everywhere.<br><br>=
My current state-of-mind (subject to change as I discover more potential at=
tacks) is that:<br><br>* The proposal to add more anchors and pre-signed tx=
s adds non-negligible complexity and hurts<br>small HTLCs, so it would be b=
etter if we didn&#39;t need it<br>* The blind CPFP carve-out trick is a one=
 shot, so you&#39;ll likely need to pay a lot of fees for it<br>to work whi=
ch still makes you lose money in case an attacker targets you (but the mone=
y goes to<br>miners, not to the attacker - unless he is the miner). It&#39;=
s potentially hard to estimate what fee<br>you should put into that blind C=
PFP carve-out because you have no idea what the current fee of the<br>pinne=
d success transaction package is, so it&#39;s unsure if that solution will =
really work in practice<br>* If we take a step back, the only attack we nee=
d to protect against is an attacker pinning a<br>preimage transaction while=
 preventing us from learning that preimage for at least `N` blocks<br>(see =
the gist for the complete explanation). Please correct me if that claim is =
incorrect as it<br>will invalidate my conclusion! Thus if we have:<br>* a h=
igh enough `cltv_expiry_delta`<br>* [off-chain preimage broadcast](<a href=
=3D"https://github.com/lightningnetwork/lightning-rfc/issues/783">https://g=
ithub.com/lightningnetwork/lightning-rfc/issues/783</a>)<br>(or David&#39;s=
 proposal to do it by sending txs that can be redeemed via only the preimag=
e)<br>* LN hubs (or any party commercially investing in running a lightning=
 node) participating in<br>various mining pools to help discover preimages<=
br>* decent mitigations for eclipse attacks<br>* then the official anchor o=
utputs proposal should be safe enough and is much simpler?<br><br>Thank you=
 for reading, I hope the work I put into this gist will be useful for some =
of you.<br><br>Bastien</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 24 avr. 2020 =C3=A0=C2=A000:47, =
Matt Corallo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.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"><br>
<br>
On 4/23/20 8:46 AM, ZmnSCPxj wrote:<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0Miners, being economically rational, accept this=
 proposal and include this in a block.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The proposal by Matt is then:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0The hashlock branch should instead be:<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0B and C must agree, and show the preimage of som=
e hash H (hashlock branch).<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0Then B and C agree that B provides a signature s=
pending the hashlock branch, to a transaction with the outputs:<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0Normal payment to C.<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0Hook output to B, which B can use to CPFP this t=
ransaction.<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0Hook output to C, which C can use to CPFP this t=
ransaction.<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0B can still (somehow) not maintain a mempool, by=
:<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0B broadcasts its timelock transaction.<br>
&gt;&gt;&gt; -=C2=A0 =C2=A0B tries to CPFP the above hashlock transaction.<=
br>
&gt;&gt;&gt; -=C2=A0 =C2=A0If CPFP succeeds, it means the above hashlock tr=
ansaction exists and B queries the peer for this transaction, extracting th=
e preimage and claiming the A-&gt;B HTLC.<br>
&gt;&gt;<br>
&gt;&gt; Note that no query is required. The problem has been solved and th=
e preimage-containing transaction should now confirm just fine.<br>
&gt; <br>
&gt; Ah, right, so it gets confirmed and the `blocksonly` B sees it in a bl=
ock.<br>
&gt; <br>
&gt; Even if C hooks a tree of low-fee transactions on its hook output or n=
ormal payment, miners will still be willing to confirm this and the B hook =
CPFP transaction without, right?<br>
<br>
Correct, once it makes it into the mempool we can CPFP it and all the regul=
ar sub-package CPFP calculation will pick it<br>
and its descendants up. Of course this relies on it not spending any other =
unconfirmed inputs.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000bc075605a86b0fbc--