path: root/b3/873033c854f64f97164487f4db0dfb8058e755

Return-Path: <laolu32@gmail.com>
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: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
 <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
 <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
 <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com>
In-Reply-To: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 22 Apr 2020 16:05:17 -0700
Message-ID: <CAO3Pvs_+Nps5Qmx2UN539+Y-2j=z0YHcKiWfHE8V0+cHn=MTkQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000008f211c05a3e92b99"
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 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 <ZmnSCPxj@protonmail.com> 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

<div dir=3D"ltr">Hi Z, <br><br>&gt; It seems to me that, if my cached under=
standing that `&lt;0&gt;<br>&gt; OP_CHECKSEQUENCEVERIFY` is sufficient to r=
equire RBF-flagging, then adding<br>&gt; that to the hashlock branch (2 wit=
ness bytes, 0.5 weight) would be a pretty<br>&gt; low-weight mitigation aga=
inst this attack.<br><br>I think this works...so they&#39;re forced to spen=
d the output with a non-final<br>sequence number, meaning it *must* signal =
RBF. In this case, now it&#39;s the<br>timeout-er vs the success-er racing =
based on fee rate. If the honest party (the<br>one trying to time out the H=
TLC) bids a fee rate higher (need to also account<br>for the whole absolute=
 fee replacement thing), then things should generally<br>work out in their =
favor.<br><br>-- Laolu<br><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj &lt=
;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt;=
 wrote:<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">Good mor=
ning Laolu, Matt, and list,<br>
<br>
<br>
&gt; &gt; =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signature<b=
r>
&gt; &gt; =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the=
 B-side<br>
&gt; &gt; =C2=A0signature for a higher-fee version of HTLC-Timeout (assumin=
g my cached<br>
&gt; &gt; =C2=A0understanding of `SIGHASH_NOINPUT` still holds).<br>
&gt;<br>
&gt; no_input isn&#39;t needed. With simply single+anyone can pay, then B c=
an attach<br>
&gt; a new input+output pair to increase the fees on their HTLC redemption<=
br>
&gt; transaction. As you mention, they now enter into a race against this<b=
r>
&gt; malicious ndoe to bump up their fees in order to win over the other pa=
rty.<br>
<br>
Right, right, that works as well.<br>
<br>
&gt;<br>
&gt; If the malicious node uses a non-RBF signalled transaction to sweep th=
eir<br>
&gt; HTLC, then we enter into another level of race, but this time on the m=
empool<br>
&gt; propagation level. However, if there exists a relay path to a miner ru=
nning<br>
&gt; full RBF, then B&#39;s higher fee rate spend will win over.<br>
<br>
Hmm.<br>
<br>
So basically:<br>
<br>
* B has no mempool, because it wants to reduce its costs and etc.<br>
* C broadcasts a non-RBF claim tx with low fee before A-&gt;B locktime (L+1=
).<br>
* B does not notice this tx because:<br>
=C2=A0 1.=C2=A0 The tx is too low fee to be put in a block.<br>
=C2=A0 2.=C2=A0 B has no mempool so it cannot see the tx being propagated o=
ver the P2P network.<br>
* B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot=
 replace a non-RBF tx.<br>
* After L+1, C contacts the miners off-band and offers fee payment by other=
 means.<br>
<br>
It seems to me that, if my cached understanding that `&lt;0&gt; 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.<br>
<br>
So I think the combination below gives us good size:<br>
<br>
* The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECAN=
PAY`.<br>
=C2=A0 * Normally, the HTLC-Timeout still deducts the fee from the value of=
 the UTXO being spent.<br>
=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.<br>
* The hashlock branch in this case includes `&lt;0&gt; OP_CHECKSEQUENCEVERI=
FY`, preventing C from broadcasting a low-fee claim tx.<br>
<br>
This has the advantages:<br>
<br>
* B does not need a mempool still and can run in `blocksonly`.<br>
* The normal path is still the same as current behavior, we &quot;only&quot=
; add a new path where if the L+1 timeout is approaching we fee-bump the HT=
LC-Timeout.<br>
* Costs are pretty low:<br>
=C2=A0 * No need for extra RBF carve-out txo.<br>
=C2=A0 * Just two additional witness bytes in the hashlock branch.<br>
* No mempool rule changes needed, can be done with the P2P network of today=
.<br>
=C2=A0 * Probably still resilient even with future changes in mempool rules=
, as long as typical RBF behaviors still remain.<br>
<br>
Is my understanding correct?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; -- Laolu<br>
&gt;<br>
&gt; On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Good morning Matt, and list,<br>
&gt; &gt;<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka &quot;=
Oh, wait, I can steal funds, how, now?&quot;)<br>
&gt; &gt; &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; &gt; &gt;<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0You&#39;ll note that in the discussion of=
 RBF pinning we were pretty broad, and that that discussion seems to in fac=
t cover<br>
&gt; &gt; &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&#3=
9;s<br>
&gt; &gt; &gt;=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,<br>
&gt; &gt; &gt;=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.<br>
&gt; &gt; &gt;=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<br>
&gt; &gt; &gt;=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.<br>
&gt; &gt;<br>
&gt; &gt; My (cached) understanding is that, since RBF is signalled using `=
nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the req=
uirement &quot;must be RBF-enabled&quot;, including `&lt;0&gt; OP_CHECKSEQU=
ENCEVERIFY`.<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; The payment is A-&gt;B-&gt;C, and the HTLC A-&gt;B must have a la=
rger timeout (L + 1) than the HTLC B-&gt;C (L), in abstract non-block units=
.<br>
&gt; &gt; The vulnerability you are describing means that the current time =
must now be L + 1 or greater (&quot;A could claim the HTLC from B via the t=
imeout mechanism&quot;, meaning the A-&gt;B HTLC has timed out already).<br=
>
&gt; &gt;<br>
&gt; &gt; If so, then the B-&gt;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.<br>
&gt; &gt; This sets up a game where B and C bid to miners to get their vers=
ion of reality committed onchain.<br>
&gt; &gt; (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.)<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt; This prevents B from RBF-ing the HTLC-Timeout transaction.<br>
&gt; &gt;<br>
&gt; &gt; So what is needed is to allow B to add fees to HTLC-Timeout:<br>
&gt; &gt;<br>
&gt; &gt; * We can add an RBF carve-out output to HTLC-Timeout, at the cost=
 of more blockspace.<br>
&gt; &gt; * 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).<br>
&gt; &gt;<br>
&gt; &gt; With this, B can exponentially increase the fee as L+1 approaches=
.<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; 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).<br>
&gt; &gt; But it does point to a need to make HTLC-Timeout (and possibly sy=
mmetrically, HTLC-Success) also fee-bumpable.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt; 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.<br>
&gt; &gt;<br>
&gt; &gt; Now, of course this only delays the war.<br>
&gt; &gt; Let us now consider what C can do to ensure that the bidding war =
will happen eventually.<br>
&gt; &gt;<br>
&gt; &gt; * C can bribe a miner to prevent HTLC-Timeout from confirming bet=
ween L and L+1.<br>
&gt; &gt; =C2=A0 * Or in other words, this is a censorship attack.<br>
&gt; &gt; =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.<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeo=
ut is precisely the mechanism we need.<br>
&gt; &gt; =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.<br>
&gt; &gt;<br>
&gt; &gt; The issue of course is the additional output that bloats the UTXO=
 set and requires another transaction to claim later.<br>
&gt; &gt; 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.<br>
&gt; &gt; (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.)<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
</blockquote></div>

--0000000000008f211c05a3e92b99--