From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11500C0175; Wed, 22 Apr 2020 23:05:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0D2F78679E; Wed, 22 Apr 2020 23:05:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg1KcEcE4Nc9; Wed, 22 Apr 2020 23:05:38 +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-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 35FFC865E0; Wed, 22 Apr 2020 23:05:38 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id v38so1897041qvf.6; Wed, 22 Apr 2020 16:05:38 -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=/dif0rrLz4K2cVPo8wzM2sEpZQJsTH225NSEYF2UOm4=; b=LtDhUp0gqJEw8QvDlzydPwYQu+A2xyba6wg4evSzMVYF00hWNjALrSPeUjEI9Vulna I3HKxVAizD5EwjmTIu/IbcjS3WEHMJbXUylzU+x7S3oDcgCAP0apVsnHlnCtgYZeoj/d Zp/sIFHtmLgrY6ZGK+nVqndKgPXjg3HQneCpnOWb9fUXRrVM5wkpf2KIeLZ71eML3qfj n3SPg/X6tDdHBnD8H8AUcnd4FKS7LpHsyjMsaU4o0byZ7NggYxrn73vTJRY9cpkKMzlO PZcHi6ofdAwYIl0ihwapjzdz2fJ5Ewa3lcyRLCZmZclKy5Kcw/fI/enVm1kRoXg+AxlD sC1g== 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=/dif0rrLz4K2cVPo8wzM2sEpZQJsTH225NSEYF2UOm4=; b=KjXZ54AlFK9qO6/EP5WbGcN2bEWa8q2QW2bVfYNnBhHqQhwePCYldI6QvmEkCw0hyD zh6B2FvJHmbmj7Qr+VDdSS5yBkXkeTO0IATJRdt8nNm+FsNHMJBL8Zhaw66Vu0Mmqauz H2EZYVOJZINzz/HaWlCqNpOSseb+exTC/pL6vKw5A3pBEyzXr8+TBcDMB08rrKxWRFNl WxaSKO/WPyJywiKVqbWfLvUsEGO5qWidOP2kJd5BOc6MXNogBF7chCsnWHsqbY+zorAW ooRmjRPi4qYPmuAcG3dxkm+OwPCR+H8KqdpFdkBo/p0+CQcUlsebWgWuxoDBZK3KEBjY o6dg== X-Gm-Message-State: AGi0PuY3iRFDKo4YpD1DSxyXeJx5WqLj7nz1IWikOmgK2QDU4WjgHBK7 XQmckgVy2xqn1NcBH+SrK0E6nIJpfv53WmTKUO4= X-Google-Smtp-Source: APiQypLLVXOUAN0CA0UglOzg6uRNgtyJWHeu5TivoE26Uz4TwVDktcv8GSMsbQ4RU3afXwhYivJNmE6cVkmPrWOnm4Y= X-Received: by 2002:a0c:b604:: with SMTP id f4mr1438648qve.40.1587596737059; Wed, 22 Apr 2020 16:05:37 -0700 (PDT) MIME-Version: 1.0 References: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com> In-Reply-To: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com> From: Olaoluwa Osuntokun Date: Wed, 22 Apr 2020 16:05:17 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000008f211c05a3e92b99" 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:05:40 -0000 --0000000000008f211c05a3e92b99 Content-Type: text/plain; charset="UTF-8" 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 > > > --0000000000008f211c05a3e92b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Z,

> It seems to me that, if my cached under= standing that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to r= equire RBF-flagging, then adding
> that to the hashlock branch (2 wit= ness bytes, 0.5 weight) would be a pretty
> low-weight mitigation aga= inst this attack.

I think this works...so they're forced to spen= d 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 H= TLC) 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 <= ;ZmnSCPxj@protonmail.com>= wrote:
Good mor= ning 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


--0000000000008f211c05a3e92b99--