path: root/85/e8c8a7de55f92de7bd190d49d688271b8c67c7

Return-Path: <laolu32@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 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: <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>
 <CAO3Pvs_+Nps5Qmx2UN539+Y-2j=z0YHcKiWfHE8V0+cHn=MTkQ@mail.gmail.com>
In-Reply-To: <CAO3Pvs_+Nps5Qmx2UN539+Y-2j=z0YHcKiWfHE8V0+cHn=MTkQ@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 22 Apr 2020 16:11:08 -0700
Message-ID: <CAO3Pvs_DeO0ym6ghEcnpJ-moYyyO2_f49jS5yp3=dG9U41B0Hg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000083402c05a3e940db"
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: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 <laolu32@gmail.com>
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 <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
>>
>>
>>

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

<div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Hi z, <br><br>A=
ctually, the current anchors proposal already does this, since it enforces =
a<br>CSV of 1 block before the HTLCs can be spent (the block after confirma=
tion). So<br>I think we already do this, meaning the malicious node is alre=
ady forced to use<br>an RBF-replaceable transaction.<br><br>-- Laolu<br></d=
iv></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Wed, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun &lt;<=
a href=3D"mailto:laolu32@gmail.com">laolu32@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Z,=
 <br><br>&gt; It seems to me that, if my cached understanding that `&lt;0&g=
t;<br>&gt; OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, t=
hen adding<br>&gt; that to the hashlock branch (2 witness bytes, 0.5 weight=
) would be a pretty<br>&gt; low-weight mitigation against this attack.<br><=
br>I think this works...so they&#39;re forced to spend the output with a no=
n-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 HTLC) bids a fee rate h=
igher (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"gmai=
l_attr">On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj &lt;<a href=3D"mailto:Zmn=
SCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wro=
te:<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 morning=
 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>
</blockquote></div>

--00000000000083402c05a3e940db--