Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BD9FEC0175; Wed, 22 Apr 2020 23:11:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id B693287787; Wed, 22 Apr 2020 23:11:31 +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 3HFIqgyK9eFx; Wed, 22 Apr 2020 23:11:29 +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-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by whitealder.osuosl.org (Postfix) with ESMTPS id AA2BC8773A; Wed, 22 Apr 2020 23:11:29 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id x12so2786271qts.9; Wed, 22 Apr 2020 16:11:29 -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=N0o7NdGVZzPPlAYqX+3TGneBSj+HqBjC/ALKAZ3944A=; b=sntRPBAgXrLKrKJ7hil5A2o9nxuSuALnAvjBgU+8rth2ayK7lhLZm7XDbJqZ9X8MI9 LZDW3udUKBtQUMxLMb+llvhiGyXMw1cjnZfruF5Ivgav+0Z6QkQqi9uGSBcQh+Q5cWta ZdRxvWBpoQmIf1GMPcL1b6F5tOjzj2bfX2DN+UaaQy/loodRUpibRQx0w0+5GtpevY64 AEoKTSsSc0iCTj4B7dOwhGGqHQRWDmsII6A0yI6Hi/GguIeMq8ryLfIjGWSBwJcI1dYD /C3Z4l8sF9R7jpS0Z39P5gV2wweFdcd1dWDZS/d7ywhZu9szWwewsX00GtyJigKbpwnM 2Xwg== 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=N0o7NdGVZzPPlAYqX+3TGneBSj+HqBjC/ALKAZ3944A=; b=TCjhLuLMkwa6smSMwTtQH7VoeSmA0BsYFi4ldyoYOBjU0O58NuPzLjOua9fMkub7/H 4RGjUFszH1odC7t7YAvx+vnJ0McGLyeWIALOIMOSj+Bfh41YN9NZSEXEBPkfKW0hZhxp +IOYho7fdYaRVk5TROYj4HCgLzzAsSLtZ8B8DGxgeg3/O1Oe8Q6MelOrUOfKkQTmLHn4 T2wK2HkzZpikIXOGoWQUqyNF0AILg7QNnR/4WOzbiUTGMnuP6jqNRPAUe9U4QRddQXrq VeZiX4uQM0Iaw4a8/r3x4ggzI3GNG7qvmd/tUMiGmy5f76MVBNBhyHdJS/vBxAlniZdi n94Q== X-Gm-Message-State: AGi0PuYms79NllHQ8ymHlNpcHRcch1AkPEfnUtZ7aHS8LMqgWgIF2JWy KWvXXdkUnrRZvLs/SmsLr3s3gjArcQS/P25b8WI= X-Google-Smtp-Source: APiQypIRhueiHg6RF25PZviR4jKevwl0R2GNmj9aTYlqE0bivcBDJIDcC0XmOMa0xhLfiqZU2j9RHRoAKwlSvm/yuQE= X-Received: by 2002:ac8:33fd:: with SMTP id d58mr1041593qtb.213.1587597088603; Wed, 22 Apr 2020 16:11:28 -0700 (PDT) MIME-Version: 1.0 References: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com> In-Reply-To: From: Olaoluwa Osuntokun Date: Wed, 22 Apr 2020 16:11:08 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000083402c05a3e940db" 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 23:11:31 -0000 --00000000000083402c05a3e940db Content-Type: text/plain; charset="UTF-8" Hi z, Actually, the current anchors proposal already does this, since it enforces a CSV of 1 block before the HTLCs can be spent (the block after confirmation). So I think we already do this, meaning the malicious node is already forced to use an RBF-replaceable transaction. -- Laolu On Wed, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun wrote: > Hi Z, > > > It seems to me that, if my cached understanding that `<0> > > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then > adding > > that to the hashlock branch (2 witness bytes, 0.5 weight) would be a > pretty > > low-weight mitigation against this attack. > > I think this works...so they're forced to spend the output with a non-final > sequence number, meaning it *must* signal RBF. In this case, now it's the > timeout-er vs the success-er racing based on fee rate. If the honest party > (the > one trying to time out the HTLC) bids a fee rate higher (need to also > account > for the whole absolute fee replacement thing), then things should generally > work out in their favor. > > -- Laolu > > > On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj wrote: > >> Good morning Laolu, Matt, and list, >> >> >> > > * 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. >> >> Right, right, that works as well. >> >> > >> > 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. >> >> Hmm. >> >> So basically: >> >> * B has no mempool, because it wants to reduce its costs and etc. >> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1). >> * B does not notice this tx because: >> 1. The tx is too low fee to be put in a block. >> 2. B has no mempool so it cannot see the tx being propagated over the >> P2P network. >> * B tries to broadcast higher-fee HTLC-timeout, but fails because it >> cannot replace a non-RBF tx. >> * After L+1, C contacts the miners off-band and offers fee payment by >> other means. >> >> It seems to me that, if my cached understanding that `<0> >> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding >> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty >> low-weight mitigation against this attack. >> >> So I think the combination below gives us good size: >> >> * The HTLC-Timeout signature from C is flagged with >> `OP_SINGLE|OP_ANYONECANPAY`. >> * Normally, the HTLC-Timeout still deducts the fee from the value of >> the UTXO being spent. >> * However, if B notices that the L+1 timeout is approaching, it can >> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature >> but reusing the (still valid) C signature. >> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`, >> preventing C from broadcasting a low-fee claim tx. >> >> This has the advantages: >> >> * B does not need a mempool still and can run in `blocksonly`. >> * The normal path is still the same as current behavior, we "only" add a >> new path where if the L+1 timeout is approaching we fee-bump the >> HTLC-Timeout. >> * Costs are pretty low: >> * No need for extra RBF carve-out txo. >> * Just two additional witness bytes in the hashlock branch. >> * No mempool rule changes needed, can be done with the P2P network of >> today. >> * Probably still resilient even with future changes in mempool rules, >> as long as typical RBF behaviors still remain. >> >> Is my understanding correct? >> >> Regards, >> ZmnSCPxj >> >> > >> > -- 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 >> >> >> --00000000000083402c05a3e940db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi z,

A= ctually, the current anchors proposal already does this, since it enforces = a
CSV of 1 block before the HTLCs can be spent (the block after confirma= tion). So
I think we already do this, meaning the malicious node is alre= ady forced to use
an RBF-replaceable transaction.

-- Laolu


On Wed, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun <<= a href=3D"mailto:laolu32@gmail.com">laolu32@gmail.com> wrote:
Hi Z,=

> It seems to me that, if my cached understanding that `<0&g= t;
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, t= hen adding
> that to the hashlock branch (2 witness bytes, 0.5 weight= ) would be a pretty
> low-weight mitigation against this attack.
<= br>I think this works...so they're forced to spend the output with a no= n-final
sequence number, meaning it *must* signal RBF. In this case, now= it's the
timeout-er vs the success-er racing based on fee rate. If = the honest party (the
one trying to time out the HTLC) bids a fee rate h= igher (need to also account
for the whole absolute fee replacement thing= ), then things should generally
work out in their favor.

-- Laolu=


On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wro= te:
Good morning= Laolu, Matt, and list,


> > =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signature > > =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the= B-side
> > =C2=A0signature for a higher-fee version of HTLC-Timeout (assumin= g my cached
> > =C2=A0understanding of `SIGHASH_NOINPUT` still holds).
>
> no_input isn't needed. With simply single+anyone can pay, then B c= an attach
> 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 > malicious ndoe to bump up their fees in order to win over the other pa= rty.

Right, right, that works as well.

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

Hmm.

So basically:

* B has no mempool, because it wants to reduce its costs and etc.
* C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1= ).
* B does not notice this tx because:
=C2=A0 1.=C2=A0 The tx is too low fee to be put in a block.
=C2=A0 2.=C2=A0 B has no mempool so it cannot see the tx being propagated o= ver the P2P network.
* B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot= replace a non-RBF tx.
* After L+1, C contacts the miners off-band and offers fee payment by other= means.

It seems to me that, if my cached understanding that `<0> OP_CHECKSEQ= UENCEVERIFY` is sufficient to require RBF-flagging, then adding that to the= hashlock branch (2 witness bytes, 0.5 weight) would be a pretty low-weight= mitigation against this attack.

So I think the combination below gives us good size:

* The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECAN= PAY`.
=C2=A0 * Normally, the HTLC-Timeout still deducts the fee from the value of= the UTXO being spent.
=C2=A0 * However, if B notices that the L+1 timeout is approaching, it can = fee-bump HTLC-Timeout with some onchain funds, recreating its own signature= but reusing the (still valid) C signature.
* The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERI= FY`, preventing C from broadcasting a low-fee claim tx.

This has the advantages:

* B does not need a mempool still and can run in `blocksonly`.
* The normal path is still the same as current behavior, we "only"= ; add a new path where if the L+1 timeout is approaching we fee-bump the HT= LC-Timeout.
* Costs are pretty low:
=C2=A0 * No need for extra RBF carve-out txo.
=C2=A0 * Just two additional witness bytes in the hashlock branch.
* No mempool rule changes needed, can be done with the P2P network of today= .
=C2=A0 * Probably still resilient even with future changes in mempool rules= , as long as typical RBF behaviors still remain.

Is my understanding correct?

Regards,
ZmnSCPxj

>
> -- 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,
> >
> > >=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 pinning we were pretty broad, and that that discussion seems to in fac= t 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= 9;s
> > >=C2=A0 =C2=A0 =C2=A0lightning protocol [2]. A lightning count= erparty (C, who received the HTLC from B, who received it from A) today cou= ld,
> > >=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transactio= n, spend an HTLC using the preimage with a low-fee, RBF-disabled transactio= n.
> > >=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTL= C from B via 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-band agreement with a small miner. This leaves B short the HTLC valu= e.
> >
> > My (cached) understanding is that, since RBF is signalled using `= nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the req= uirement "must be RBF-enabled", including `<0> OP_CHECKSEQU= ENCEVERIFY`.
> > 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-disab= led transaction.
> >
> > But then you mention out-of-band agreements with miners, which ba= sically 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 economic= s.
> >
> > The payment is A->B->C, and the HTLC A->B must have a la= rger 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 t= imeout 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 hashl= ock branch.
> > This sets up a game where B and C bid to miners to get their vers= ion of reality committed onchain.
> > (We can neglect out-of-band agreements here; miners have the ince= ntive 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 a= ll will leak the preimage, which B can then turn around and use to spend fr= om A, and A and C cannot steal from B.
> >
> > Thus, B should ensure that *before* L+1, the HTLC-Timeout has bee= n committed onchain, which outright prevents this bidding war from even sta= rting.
> >
> > The issue then is that B is using a pre-signed HTLC-timeout, whic= h 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 `SIGHAS= H_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 `S= IGHASH_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 ste= al the HTLC value at all, since the UTXO it could steal from has already be= en spent.
> >
> > In particular, it does not seem to me that it is necessary to cha= nge the hashlock-branch transaction of C at all, since this mechanism is en= ough to sidestep the issue (as I understand it).
> > But it does point to a need to make HTLC-Timeout (and possibly sy= mmetrically, 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 i= ts own commitment transaction, and B *should* be aware that it did so --- t= here 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 bet= ween 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 c= ensored transactions can be fee-bumped, which attracts non-censoring miners= to try their luck at mining and evict the censoring miner.
> > =C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeo= ut is precisely the mechanism we need.
> > =C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C reque= sting miners to censor, vs. B requesting miners to confirm, but that only s= ets 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, wherea= s B can offer its bribe as being something that miners can claim now withou= t 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-Russ= ell-Osuntokun sidesteps this issue as well, as any timed-out HTLC can be cl= aimed 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-R= ussell-Osuntokun channel: sign a transaction spending the funding tx to a t= xo that has been set up as Decker-Russell-Osuntokun, do not broadcast that = transaction, then revoke the latest Poon-Dryja commitment transactions, the= n switch the mechanism over to Decker-Russell-Osuntokun; you still need to = monitor for previous Poon-Dryja commitment transactions, but HTLCs now side= step the issue under discussion here.)
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev


--00000000000083402c05a3e940db--