path: root/af/d7b13f5cd0ad1b23bd4b93760595037440da16

Return-Path: <laolu32@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CBD06C0175;
 Wed, 22 Apr 2020 04:18:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id C2A4F85692;
 Wed, 22 Apr 2020 04:18:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LMcpGIF-SRgo; Wed, 22 Apr 2020 04:18:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com
 [209.85.222.177])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 3FB3984F27;
 Wed, 22 Apr 2020 04:18:51 +0000 (UTC)
Received: by mail-qk1-f177.google.com with SMTP id 20so1117352qkl.10;
 Tue, 21 Apr 2020 21:18:51 -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
 :cc; bh=C2oEEJ1kkYujvjaVvSmn2RnMU70jTfqfvH6sRY+OQzw=;
 b=HBrNeK24ykrskdjanSk9WV4Yy8LauR1Awgfw+JP2cdDVLP8sxvtVtBM/P06NsuYDCk
 vsU03uozx7Pr/bjlain07DJ99ZgOQQxAlfUmnb9+WM3KmfwB6Gr33/Hebt30XOmWvWSA
 MtT7swtxz+ul4agkpGZy39gN2Hisu8/PyAx6cdiAhlTzAM3pQi32JTYQA6KS7/OoHRR4
 cj4RdPagH9tpi3eO22uQJ7uFZJfExPgGLtZTVhBwXbXTAywPW4Pt9u+EQbyCsyFMdISh
 qNs6WOv/y/5wMkTDhebFgPNp3AoorFUtt2XtBPb3G782uOXwbFaKRENHpdJaSXZYvNh0
 1D7Q==
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=C2oEEJ1kkYujvjaVvSmn2RnMU70jTfqfvH6sRY+OQzw=;
 b=RtCq1v8RGI6ZUPzEftwoDnSHEyVGCWzV411Lq3+2lLhfmdqPxnjwKZ7+H5Ju9nsFEi
 yGzGkwCVshJkcACtUssXtmYBoyDc+JxFDdeXSLH+lqjOwEwGAGA5jFsj5gBGH5jEi2Hy
 SQK/It4RmyCKNCM/7E9oY/gT2nZZjMvY2fy68DZt74+1C+8RBMd3p60I6/Bl4phZm+gv
 JAlB3iwCJRSvyObuCaNrH8j2RxjBnFhvml6PeDVyoOsd7nNI4jXRkbJEPRPhkThlo1ft
 g/kLIThZ9CCsZi4woT70FQ8F5/yv52k4R4eDPbYrZWyiRynZzFPB6b4WwoJcEJxHsT0U
 oF7g==
X-Gm-Message-State: AGi0PubIQcmO9N/WFBnX1bfo8DZ8bIaw7INLBlkiYCZ1AD2v+rzh6vEz
 bJRa0OmNf5XSfnYhM/xHaG7aNk80hBwuN2zBvtA=
X-Google-Smtp-Source: APiQypLq+pxJWCP8Guj94oIL/ay3xrX0kUjRsfSbuDwCpKuydRnlRkMfEMrWFUbpM07EPkj+DRdx98Y5QNCnEt+Do24=
X-Received: by 2002:a37:6393:: with SMTP id
 x141mr23160542qkb.179.1587529129996; 
 Tue, 21 Apr 2020 21:18:49 -0700 (PDT)
MIME-Version: 1.0
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
 <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
In-Reply-To: <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 21 Apr 2020 21:18:29 -0700
Message-ID: <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000dd359f05a3d96def"
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: Wed, 22 Apr 2020 04:18:52 -0000

--000000000000dd359f05a3d96def
Content-Type: text/plain; charset="UTF-8"

> So what is needed is to allow B to add fees to HTLC-Timeout:

Indeed, anchors as defined in #lightning-rfc/688 allows this.

>  * With `SIGHASH_NOINPUT` we can make the C-side signature
>  `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
>  signature for a higher-fee version of HTLC-Timeout (assuming my cached
>  understanding of `SIGHASH_NOINPUT` still holds).

no_input isn't needed. With simply single+anyone can pay, then B can attach
a new input+output pair to increase the fees on their HTLC redemption
transaction. As you mention, they now enter into a race against this
malicious ndoe to bump up their fees in order to win over the other party.

If the malicious node uses a non-RBF signalled transaction to sweep their
HTLC, then we enter into another level of race, but this time on the mempool
propagation level. However, if there exists a relay path to a miner running
full RBF, then B's higher fee rate spend will win over.

-- Laolu

On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Matt, and list,
>
>
>
> >     RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds,
> how, now?")
> >     =============================
> >
> >     You'll note that in the discussion of RBF pinning we were pretty
> broad, and that that discussion seems to in fact cover
> >     our HTLC outputs, at least when spent via (3) or (4). It does, and
> in fact this is a pretty severe issue in today's
> >     lightning protocol [2]. A lightning counterparty (C, who received
> the HTLC from B, who received it from A) today could,
> >     if B broadcasts the commitment transaction, spend an HTLC using the
> preimage with a low-fee, RBF-disabled transaction.
> >     After a few blocks, A could claim the HTLC from B via the timeout
> mechanism, and then after a few days, C could get the
> >     HTLC-claiming transaction mined via some out-of-band agreement with
> a small miner. This leaves B short the HTLC value.
>
> My (cached) understanding is that, since RBF is signalled using
> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
> Adding that clause (2 bytes in witness if my math is correct) to the
> hashlock branch may be sufficient to prevent C from making an RBF-disabled
> transaction.
>
> But then you mention out-of-band agreements with miners, which basically
> means the transaction might not be in the mempool at all, in which case the
> vulnerability is not really about RBF or relay, but sheer economics.
>
> The payment is A->B->C, and the HTLC A->B must have a larger timeout (L +
> 1) than the HTLC B->C (L), in abstract non-block units.
> The vulnerability you are describing means that the current time must now
> be L + 1 or greater ("A could claim the HTLC from B via the timeout
> mechanism", meaning the A->B HTLC has timed out already).
>
> If so, then the B->C transaction has already timed out in the past and can
> be claimed in two ways, either via B timeout branch or C hashlock branch.
> This sets up a game where B and C bid to miners to get their version of
> reality committed onchain.
> (We can neglect out-of-band agreements here; miners have the incentive to
> publicly leak such agreements so that other potential bidders can offer
> even higher fees for their versions of that transaction.)
>
> Before L+1, C has no incentive to bid, since placing any bid at all will
> leak the preimage, which B can then turn around and use to spend from A,
> and A and C cannot steal from B.
>
> Thus, B should ensure that *before* L+1, the HTLC-Timeout has been
> committed onchain, which outright prevents this bidding war from even
> starting.
>
> The issue then is that B is using a pre-signed HTLC-timeout, which is
> needed since it is its commitment tx that was broadcast.
> This prevents B from RBF-ing the HTLC-Timeout transaction.
>
> So what is needed is to allow B to add fees to HTLC-Timeout:
>
> * We can add an RBF carve-out output to HTLC-Timeout, at the cost of more
> blockspace.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of HTLC-Timeout (assuming my cached
> understanding of `SIGHASH_NOINPUT` still holds).
>
> With this, B can exponentially increase the fee as L+1 approaches.
> If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the
> HTLC value at all, since the UTXO it could steal from has already been
> spent.
>
> In particular, it does not seem to me that it is necessary to change the
> hashlock-branch transaction of C at all, since this mechanism is enough to
> sidestep the issue (as I understand it).
> But it does point to a need to make HTLC-Timeout (and possibly
> symmetrically, HTLC-Success) also fee-bumpable.
>
> Note as well that this does not require a mempool: B can run in
> `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout
> is not confirmed, feebump HTLC-Timeout.
> In particular, HTLC-Timeout comes into play only if B broadcast its own
> commitment transaction, and B *should* be aware that it did so --- there is
> still no need for mempool monitoring here.
>
>
> Now, of course this only delays the war.
> Let us now consider what C can do to ensure that the bidding war will
> happen eventually.
>
> * C can bribe a miner to prevent HTLC-Timeout from confirming between L
> and L+1.
>   * Or in other words, this is a censorship attack.
>     * The Bitcoin censorship-resistance model is that censored
> transactions can be fee-bumped, which attracts non-censoring miners to try
> their luck at mining and evict the censoring miner.
>       * Thus, letting B bump the fee on HTLC-Timeout is precisely the
> mechanism we need.
>       * This sets up a bidding war between C requesting miners to censor,
> vs. B requesting miners to confirm, but that only sets the stage for a
> second bidding war later between C and B, thus C is at a disadvantage: it
> has to bribe miners to censor continuously from L to L+1 *and* additional
> bribe miners to confirm its transaction after L+1, whereas B can offer its
> bribe as being something that miners can claim now without waiting after
> L+1.
>
>
>
> The issue of course is the additional output that bloats the UTXO set and
> requires another transaction to claim later.
> And if we have `SIGHASH_NOINPUT`, it seems to me that
> Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out
> HTLC can be claimed with a fee-bumpable transaction directly without
> RBF-carve-out.
> (As well, it seems to me that, if both nodes support doing so, a
> Poon-Dryja channel can be upgraded, without onchain activity, to a
> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
> broadcast that transaction, then revoke the latest Poon-Dryja commitment
> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
> you still need to monitor for previous Poon-Dryja commitment transactions,
> but HTLCs now sidestep the issue under discussion here.)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; So what is needed is to allow B to add fees to HTLC-T=
imeout:<br><br>Indeed, anchors as defined in #lightning-rfc/688 allows this=
.<br><br>&gt; =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signatu=
re<br>&gt; =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign th=
e B-side<br>&gt; =C2=A0signature for a higher-fee version of HTLC-Timeout (=
assuming my cached<br>&gt; =C2=A0understanding of `SIGHASH_NOINPUT` still h=
olds).<br><br>no_input isn&#39;t needed. With simply single+anyone can pay,=
 then B can attach<br>a new input+output pair to increase the fees on their=
 HTLC redemption<br>transaction. As you mention, they now enter into a race=
 against this<br>malicious ndoe to bump up their fees in order to win over =
the other party.<br><br>If the malicious node uses a non-RBF signalled tran=
saction to sweep their<br>HTLC, then we enter into another level of race, b=
ut this time on the mempool<br>propagation level. However, if there exists =
a relay path to a miner running<br>full RBF, then B&#39;s higher fee rate s=
pend will win over. <br><br>-- Laolu<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 21, 2020 at 9:13 PM Zmn=
SCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Good morning Matt, and list,<b=
r>
<br>
<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka &quot;Oh, wait, =
I can steal funds, how, now?&quot;)<br>
&gt;=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0You&#39;ll note that in the discussion of RBF pinni=
ng we were pretty broad, and that that discussion seems to in fact cover<br=
>
&gt;=C2=A0 =C2=A0 =C2=A0our HTLC outputs, at least when spent via (3) or (4=
). It does, and in fact this is a pretty severe issue in today&#39;s<br>
&gt;=C2=A0 =C2=A0 =C2=A0lightning protocol [2]. A lightning counterparty (C=
, who received the HTLC from B, who received it from A) today could,<br>
&gt;=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transaction, spend a=
n HTLC using the preimage with a low-fee, RBF-disabled transaction.<br>
&gt;=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTLC from B v=
ia the timeout mechanism, and then after a few days, C could get the<br>
&gt;=C2=A0 =C2=A0 =C2=A0HTLC-claiming transaction mined via some out-of-ban=
d agreement with a small miner. This leaves B short the HTLC value.<br>
<br>
My (cached) understanding is that, since RBF is signalled using `nSequence`=
, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requirement &=
quot;must be RBF-enabled&quot;, including `&lt;0&gt; OP_CHECKSEQUENCEVERIFY=
`.<br>
Adding that clause (2 bytes in witness if my math is correct) to the hashlo=
ck branch may be sufficient to prevent C from making an RBF-disabled transa=
ction.<br>
<br>
But then you mention out-of-band agreements with miners, which basically me=
ans the transaction might not be in the mempool at all, in which case the v=
ulnerability is not really about RBF or relay, but sheer economics.<br>
<br>
The payment is A-&gt;B-&gt;C, and the HTLC A-&gt;B must have a larger timeo=
ut (L + 1) than the HTLC B-&gt;C (L), in abstract non-block units.<br>
The vulnerability you are describing means that the current time must now b=
e L + 1 or greater (&quot;A could claim the HTLC from B via the timeout mec=
hanism&quot;, meaning the A-&gt;B HTLC has timed out already).<br>
<br>
If so, then the B-&gt;C transaction has already timed out in the past and c=
an be claimed in two ways, either via B timeout branch or C hashlock branch=
.<br>
This sets up a game where B and C bid to miners to get their version of rea=
lity committed onchain.<br>
(We can neglect out-of-band agreements here; miners have the incentive to p=
ublicly leak such agreements so that other potential bidders can offer even=
 higher fees for their versions of that transaction.)<br>
<br>
Before L+1, C has no incentive to bid, since placing any bid at all will le=
ak the preimage, which B can then turn around and use to spend from A, and =
A and C cannot steal from B.<br>
<br>
Thus, B should ensure that *before* L+1, the HTLC-Timeout has been committe=
d onchain, which outright prevents this bidding war from even starting.<br>
<br>
The issue then is that B is using a pre-signed HTLC-timeout, which is neede=
d since it is its commitment tx that was broadcast.<br>
This prevents B from RBF-ing the HTLC-Timeout transaction.<br>
<br>
So what is needed is to allow B to add fees to HTLC-Timeout:<br>
<br>
* We can add an RBF carve-out output to HTLC-Timeout, at the cost of more b=
lockspace.<br>
* With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHASH_NOINPUT|=
SIGHASH_SINGLE` and allow B to re-sign the B-side signature for a higher-fe=
e version of HTLC-Timeout (assuming my cached understanding of `SIGHASH_NOI=
NPUT` still holds).<br>
<br>
With this, B can exponentially increase the fee as L+1 approaches.<br>
If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the HTL=
C value at all, since the UTXO it could steal from has already been spent.<=
br>
<br>
In particular, it does not seem to me that it is necessary to change the ha=
shlock-branch transaction of C at all, since this mechanism is enough to si=
destep the issue (as I understand it).<br>
But it does point to a need to make HTLC-Timeout (and possibly symmetricall=
y, HTLC-Success) also fee-bumpable.<br>
<br>
Note as well that this does not require a mempool: B can run in `blocksonly=
` mode and as each block comes in from L to L+1, if HTLC-Timeout is not con=
firmed, feebump HTLC-Timeout.<br>
In particular, HTLC-Timeout comes into play only if B broadcast its own com=
mitment transaction, and B *should* be aware that it did so --- there is st=
ill no need for mempool monitoring here.<br>
<br>
<br>
Now, of course this only delays the war.<br>
Let us now consider what C can do to ensure that the bidding war will happe=
n eventually.<br>
<br>
* C can bribe a miner to prevent HTLC-Timeout from confirming between L and=
 L+1.<br>
=C2=A0 * Or in other words, this is a censorship attack.<br>
=C2=A0 =C2=A0 * The Bitcoin censorship-resistance model is that censored tr=
ansactions can be fee-bumped, which attracts non-censoring miners to try th=
eir luck at mining and evict the censoring miner.<br>
=C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeout is prec=
isely the mechanism we need.<br>
=C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C requesting mine=
rs to censor, vs. B requesting miners to confirm, but that only sets the st=
age for a second bidding war later between C and B, thus C is at a disadvan=
tage: it has to bribe miners to censor continuously from L to L+1 *and* add=
itional bribe miners to confirm its transaction after L+1, whereas B can of=
fer its bribe as being something that miners can claim now without waiting =
after L+1.<br>
<br>
<br>
<br>
The issue of course is the additional output that bloats the UTXO set and r=
equires another transaction to claim later.<br>
And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Osunto=
kun sidesteps this issue as well, as any timed-out HTLC can be claimed with=
 a fee-bumpable transaction directly without RBF-carve-out.<br>
(As well, it seems to me that, if both nodes support doing so, a Poon-Dryja=
 channel can be upgraded, without onchain activity, to a Decker-Russell-Osu=
ntokun channel: sign a transaction spending the funding tx to a txo that ha=
s been set up as Decker-Russell-Osuntokun, do not broadcast that transactio=
n, then revoke the latest Poon-Dryja commitment transactions, then switch t=
he mechanism over to Decker-Russell-Osuntokun; you still need to monitor fo=
r previous Poon-Dryja commitment transactions, but HTLCs now sidestep the i=
ssue under discussion here.)<br>
<br>
Regards,<br>
ZmnSCPxj<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>

--000000000000dd359f05a3d96def--