From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: In-Reply-To: From: Olaoluwa Osuntokun Date: Tue, 21 Apr 2020 21:18:29 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000dd359f05a3d96def" Cc: Bitcoin Protocol Discussion , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> So what is needed is to allow B to add fees to HTLC-T= imeout:

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

> =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signatu= re
> =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign th= e B-side
> =C2=A0signature for a higher-fee version of HTLC-Timeout (= assuming my cached
> =C2=A0understanding of `SIGHASH_NOINPUT` still h= olds).

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 tran= saction to sweep their
HTLC, then we enter into another level of race, b= ut 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 s= pend will win over.

-- Laolu

On Tue, Apr 21, 2020 at 9:13 PM Zmn= SCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good morning Matt, and list,


>=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka "Oh, wait, = I can steal funds, how, now?")
>=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
>
>=C2=A0 =C2=A0 =C2=A0You'll note that in the discussion of RBF pinni= ng we were pretty broad, and that that discussion seems to in fact cover >=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's
>=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,
>=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.
>=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
>=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.

My (cached) understanding is that, since RBF is signalled using `nSequence`= , any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requirement &= quot;must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY= `.
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.

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.

The payment is A->B->C, and the HTLC A->B must have a larger timeo= ut (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 b= e L + 1 or greater ("A could claim the HTLC from B via the timeout mec= hanism", meaning the A->B HTLC has timed out already).

If so, then the B->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= .
This sets up a game where B and C bid to miners to get their version of rea= lity committed onchain.
(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.)

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.

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.

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.
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 b= lockspace.
* 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).

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 HTL= C value at all, since the UTXO it could steal from has already been spent.<= 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).
But it does point to a need to make HTLC-Timeout (and possibly symmetricall= y, 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 con= firmed, feebump HTLC-Timeout.
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.


Now, of course this only delays the war.
Let us now consider what C can do to ensure that the bidding war will happe= n eventually.

* C can bribe a miner to prevent HTLC-Timeout from confirming between L and= L+1.
=C2=A0 * Or in other words, this is a censorship attack.
=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.
=C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeout is prec= isely the mechanism we need.
=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.



The issue of course is the additional output that bloats the UTXO set and r= equires another transaction to claim later.
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.
(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.)

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000dd359f05a3d96def--