path: root/76/618719a1084908ecb84487aa5332f19fe86234

Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BEE6DC0175;
 Wed, 22 Apr 2020 08:01:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id AA9C82153D;
 Wed, 22 Apr 2020 08:01:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id shUAJbFAXQHN; Wed, 22 Apr 2020 08:01:39 +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-pl1-f175.google.com (mail-pl1-f175.google.com
 [209.85.214.175])
 by silver.osuosl.org (Postfix) with ESMTPS id 0F77D21537;
 Wed, 22 Apr 2020 08:01:39 +0000 (UTC)
Received: by mail-pl1-f175.google.com with SMTP id z6so622284plk.10;
 Wed, 22 Apr 2020 01:01:39 -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=rQv3rptFNcz8TgItBiRrPdPIZW06AnI/cqw+aqyOHu0=;
 b=Fa6+HlOjVv9AUNvneN38YvR6eBAOSujiMDwt3gBJUe7fTBMlHbktu0YWvQgXhmacI1
 cNRPX2VgZVbzqMtINMqx+VcOy1ezwbRpTUFTifrcySG4xAwINXwy3zCz3Mf2vXXVXiDD
 1/HtGrMpFN/YmHv9Luw3QD1orwQ30cw91ckRP7nun6jMKVZvC8inmkzTB/XacBmY58OM
 znWeWEaSH3l6xxXB3Pi4BXtMcAFhyZl2mOdQv1urtXrMCaBunO2kL9lr6YHGgj3wOB66
 bXEbrvbSeOQdYPAbIo3bl+J8AjjIZcnFRifBw8aaVGWq96itn2+P+ttSxgYQ/cpLSjQO
 xQRw==
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=rQv3rptFNcz8TgItBiRrPdPIZW06AnI/cqw+aqyOHu0=;
 b=oiZ41qKsx/Wm5GLbmYOJyeQhwc8W3P/jxnvP0pIZK/JQQH8RprdULj6JA2MV+Dlyiu
 Olsuh4YJ2EjRNrJ3X/uNFSVXCxnwEZ7knlP9yk7P/iz4In40IDM5n207ZKp+bZLl67FP
 baAHqH76815iFRyHxygyZtbgtaGo+9G9XVcLr7rl2i7Kudqo0ft2mu4FV5uT75lVEawk
 tk+lqFcRSlvlWqJzsJzurbZ+kkrSMfa9n2F3wk8k5se9tMiKfks7bXu4H6IjQxqwceiO
 6s21tFgaNwdPm71iDUuZWDdwjdIzghBM/rGlNKzM8bvjOZNd43J0fpwmvKxLr/4hzRNb
 a5Kw==
X-Gm-Message-State: AGi0PuYGJJqZBFiH6XPqI8iKQW+RI6zGqAqxH64gQqIySXei7mNRwBiJ
 o2erMGe5/+ys7O2vx2WXXSwYmttb3gRgsRnyvbqWc6pv
X-Google-Smtp-Source: APiQypJLOM/0a84oTG4ijBoduNVBzxeOYRGdw2BNCAMNJp4SmRYWUmRFVDpScmHIaLZps1FIFMnfBM8V/bmdoiFFzFs=
X-Received: by 2002:a17:90a:2e87:: with SMTP id
 r7mr7588238pjd.38.1587542498285; 
 Wed, 22 Apr 2020 01:01:38 -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: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 22 Apr 2020 04:01:23 -0400
Message-ID: <CALZpt+HFyh3X9nBvMnQ8C8T_ijahDrNsCsz0Qk_ogS5zM_BPBA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ad1bcc05a3dc8a77"
X-Mailman-Approved-At: Wed, 22 Apr 2020 09:05:20 +0000
Cc: 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 08:01:47 -0000

--000000000000ad1bcc05a3dc8a77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Personally, I would have wait a bit before to go public on this, like
letting some implementations
increasing their CLTV deltas, but anyway, it's here now.

Mempool-pinning attacks were already discussed on this list [0], but what
we found is you
can _reverse_ the scenario, where it's not the malicious party delaying
confirmation of honest
party transactions but malicious deliberately stucking its own transactions
in the mempool to avoid
confirmation of timeout. And therefore gaming inter-link timelock to
provoke an unbalanced
settlement for the victim ("aka you pay forward, but don't get pay
backward").

How much attacks are practical is based on how you can leverage mempool
rules to pin your own
transaction. What you're looking for is a  _mempool-obstruction_ trick, i.e
a way to get honest party
transaction being bounce off due to your transaction being already there.

Beyond disabling RBF on your transaction (with current protocol, not anchor
proposal), there is
two likely candidates:
* BIP 125 rule 3: "The replacement transaction pays an absolute fee of at
least the sum paid by the original transactions."
* BIP 125 rule 5: "The number of original transactions to be replaced and
their descendant transactions which will be evicted from the mempool must
not exceed a total of 100 transactions."

Let's go through whole scenario:
* Mallory and Eve are colluding
* Eve and Mallory are opening channels with Alice, Mallory do a bit of
rebalancing
to get full incoming capacity, like receiving funds on an onchain address
through another Alice
link
* Eve send a HTLC #1 to Mallory through Alice expirying at block 100
* Eve send a second HTLC #2 to Mallory through Alice, expirying at block
110 on outgoing link
(A<->M), 120 on incoming link (E<->A)
* Before block 100, without cancellation from Mallory, Alice will
force-close channel and broadcast
her local commitment and HTLC-timeout to get back HTLC #1
* Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at 11=
0
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
on Alice's transaction,
feerate is maliciously chosen to get in network mempools but never to
confirm. Absolute fee must
be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
race.
* As Alice doesn't watch the mempool, she is never going to learn the
preimage to redeeem incoming
HTLC #2
* At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may be
higher but as absolute
fee is lower, it's going to be rejected from network mempools as
replacement for Pinning Preimage
Tx (BIP 125 rule 3)
* At block 120, Eve closes channel and HTLC-timeout HTLC #2
* Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it
confirmed

New anchor_output proposal, by disabling RBF, forces attacker to bid on the
absolute fee. It may
be now a risk to loose the fee if Pinning Tx is confirming. You may extend
your "pinning
lease" by ejecting your malicious tx, like conflicting or trimming out of
the mempool one of its
parents. And then reannounce your preimage tx with a
lower-feerate-but-still-high-fee before a
new block and a honest HTLC-timeout rebroadcast.

AFAICT, even with anchor_output deployed, even assuming empty mempools,
success rate and economic
rationality of attacks is finding such cheap, reliable "pinning lease
extension" trick.

I think any mempool watching mitigation is at best a cat-and-mouse hack.
Contrary to node
advancing towards a global blockchain view thanks to PoW, network mempools
don't have a convergence
guarantee. This means,  in a distributed system like bitcoin, node don't
see events in the same
order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,
tx Y. And order of events
affects if a future event is going to be rejected or not, like if tx Z
disable-RBF and tx X try to
replace Z, Alice accepts X and Bob rejects it. And this divergence may
perserve until a new block.

Practically, it means an attacker can provoke a local conflict to bounce
off HTLC preimage tx out
of your mempool while broadcasting preimage tx without conflict to the rest
of the network by
tweaking tx-relay protocol and so easily manipulating order of events for
every node. A local
conflict is easy to provoke, just make tx A double-spent by both
HTLC-preimage-tx and non-RBF-tx-B.
Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of
network. When rest of
network announce HTLC-preimage-tx, it's going to rejected by your mempool.

Provoking local conflict assumes of course _interlayer_ mapping by an
attacker, i.e mapping your LN
node to your full-node(s). Last time, we check, there was 982 match by IP
for 4,500 LN/52,000
full-node. Mapping heuristics is an ongoing research subject and sadly
seems affordable.

Yes a) you can enable full-RBF on your local node but blinding conflicting
may still be with higher
feerate as everything is attacker malleable b) you may want to catch tx and
extract preimage
on the p2p wire, but processing raw transaction would be such a DoS
vector...

Overall, I think we all agree on the long term direction to get a
Contracting-Protocols-Enhanced
mempool with a multiparty-safe-API, bundled with package relay deployment.
Even if there is current
move toward this direction, this may take longer than expected as with any
critical-safety
component in Core.

A temporary fix could be to resuscitate old work to ensure peering through
a full-RBF propagation path,
but p2p implications are hard to gauge, like wouldn't guarantee p2p
censorship resistance of this...

It's quite a tangled issue, with a good deal of both bitcoin and lightning
knowledge so feel free
to verify and double-check more than usual

Cheers

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/0022=
40.html

Le mer. 22 avr. 2020 =C3=A0 02:08, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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 cach=
ed
> > >  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 the=
ir
> > 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 addin=
g
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pret=
ty
> 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 th=
e
> 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 signatu=
re
> 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, a=
s
> 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?")
> > > >     =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
> > > >
> > > >     You'll note that in the discussion of RBF pinning we were prett=
y
> 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-disable=
d
> 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 an=
d
> 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 incentiv=
e
> to publicly leak such agreements so that other potential bidders can offe=
r
> 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 fro=
m
> 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 bee=
n
> 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 enou=
gh
> 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-Timeo=
ut
> 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 tr=
y
> 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, where=
as
> 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-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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Personally, I would have wait a bit before to go publ=
ic on this, like letting some implementations <br>increasing their CLTV del=
tas, but anyway, it&#39;s here now.<br>=C2=A0<br>Mempool-pinning attacks we=
re already discussed on this list [0], but what we found is you<br>can _rev=
erse_ the scenario, where it&#39;s not the malicious party delaying confirm=
ation of honest<br>party transactions but malicious deliberately stucking i=
ts own transactions in the mempool to avoid<br>confirmation of timeout. And=
 therefore gaming inter-link timelock to provoke an unbalanced<br>settlemen=
t for the victim (&quot;aka you pay forward, but don&#39;t get pay backward=
&quot;).<br><br>How much attacks are practical is based on how you can leve=
rage mempool rules to pin your own<br>transaction. What you&#39;re looking =
for is a=C2=A0 _mempool-obstruction_ trick, i.e a way to get honest party<b=
r>transaction being bounce off due to your transaction being already there.=
<br><br>Beyond disabling RBF on your transaction (with current protocol, no=
t anchor proposal), there is<br>two likely candidates:<br>* BIP 125 rule 3:=
 &quot;The replacement transaction pays an absolute fee of at least the sum=
 paid by the original transactions.&quot;<br>* BIP 125 rule 5: &quot;The nu=
mber of original transactions to be replaced and their descendant transacti=
ons which will be evicted from the mempool must not exceed a total of 100 t=
ransactions.&quot;<br><br>Let&#39;s go through whole scenario:<br>* Mallory=
 and Eve are colluding<br>* Eve and Mallory are opening channels with Alice=
, Mallory do a bit of rebalancing<br>to get full incoming capacity, like re=
ceiving funds on an onchain address through another Alice<br>link<br>* Eve =
send a HTLC #1 to Mallory through Alice expirying at block 100<br>* Eve sen=
d a second HTLC #2 to Mallory through Alice, expirying at block 110 on outg=
oing link<br>(A&lt;-&gt;M), 120 on incoming link (E&lt;-&gt;A)<br>* Before =
block 100, without cancellation from Mallory, Alice will force-close channe=
l and broadcast<br>her local commitment and HTLC-timeout to get back HTLC #=
1<br>* Alice can&#39;t broadcast HTLC-timeout for HTLC #2 as it&#39;s only =
expires at 110<br>* Mallory can broadcast its Pinning Preimage Tx on offere=
d HTLC #2 output on Alice&#39;s transaction,<br>feerate is maliciously chos=
en to get in network mempools but never to confirm. Absolute fee must<br>be=
 higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p race=
.<br>* As Alice doesn&#39;t watch the mempool, she is never going to learn =
the preimage to redeeem incoming<br>HTLC #2<br>* At block 110, Alice is goi=
ng to broadcast HTLC-timeout #2, feerate may be higher but as absolute<br>f=
ee is lower, it&#39;s going to be rejected from network mempools as replace=
ment for Pinning Preimage<br>Tx (BIP 125 rule 3)<br>* At block 120, Eve clo=
ses channel and HTLC-timeout HTLC #2<br>* Mallory can RBF its Pinning Preim=
age Tx by a high-feerate one and get it confirmed<br><br>New anchor_output =
proposal, by disabling RBF, forces attacker to bid on the absolute fee. It =
may<br>be now a risk to loose the fee if Pinning Tx is confirming. You may =
extend your &quot;pinning<br>lease&quot; by ejecting your malicious tx, lik=
e conflicting or trimming out of the mempool one of its<br>parents. And the=
n reannounce your preimage tx with a lower-feerate-but-still-high-fee befor=
e a<br>new block and a honest HTLC-timeout rebroadcast.<br><br>AFAICT, even=
 with anchor_output deployed, even assuming empty mempools, success rate an=
d economic<br>rationality of attacks is finding such cheap, reliable &quot;=
pinning lease extension&quot; trick.<br><br>I think any mempool watching mi=
tigation is at best a cat-and-mouse hack. Contrary to node <br>advancing to=
wards a global blockchain view thanks to PoW, network mempools don&#39;t ha=
ve a convergence<br>guarantee. This means, =C2=A0in a distributed system li=
ke bitcoin, node don&#39;t see events in the same<br>order, Alice may obser=
ve tx X, tx Y, tx Z and Bob may observe tx Z, tx X, tx Y. And order of even=
ts<br>affects if a future event is going to be rejected or not, like if tx =
Z disable-RBF and tx X try to<br>replace Z, Alice accepts X and Bob rejects=
 it. And this divergence may perserve until a new block.<br><br>Practically=
, it means an attacker can provoke a local conflict to bounce off HTLC prei=
mage tx out <br>of your mempool while broadcasting preimage tx without conf=
lict to the rest of the network by<br>tweaking tx-relay protocol and so eas=
ily manipulating order of events for every node. A local<br>conflict is eas=
y to provoke, just make tx A double-spent by both HTLC-preimage-tx and non-=
RBF-tx-B.<br>Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to=
 rest of network. When rest of <br>network announce HTLC-preimage-tx, it&#3=
9;s going to rejected by your mempool.<br><br>Provoking local conflict assu=
mes of course _interlayer_ mapping by an attacker, i.e mapping your LN<br>n=
ode to your full-node(s). Last time, we check, there was 982 match by IP fo=
r 4,500 LN/52,000<br>full-node. Mapping heuristics is an ongoing research s=
ubject and sadly seems affordable.<br><br>Yes a) you can enable full-RBF on=
 your local node but blinding conflicting may still be with higher<br>feera=
te as everything is attacker malleable b) you may want to catch tx and extr=
act preimage<br>on the p2p wire, but processing raw transaction would be su=
ch a DoS vector...<br><br>Overall, I think we all agree on the long term di=
rection to get a Contracting-Protocols-Enhanced<br>mempool with a multipart=
y-safe-API, bundled with package relay deployment. Even if there is current=
<br>move toward this direction, this may take longer than expected as with =
any critical-safety<br>component in Core.<br><br><div>A temporary fix could=
 be to resuscitate old work to ensure peering through a full-RBF propagatio=
n path,</div><div>but p2p implications are hard to gauge, like wouldn&#39;t=
 guarantee p2p censorship resistance of this...<br></div><br></div><div>It&=
#39;s quite a tangled issue, with a good deal of both bitcoin and lightning=
 knowledge so feel free</div><div>to verify and double-check more than usua=
l<br></div><div><br>Cheers<br><br>[0] <a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2019-October/002240.html">https://lists.lin=
uxfoundation.org/pipermail/lightning-dev/2019-October/002240.html</a><br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">Le=C2=A0mer. 22 avr. 2020 =C3=A0=C2=A002:08, ZmnSCPxj via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cla=
ss=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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ad1bcc05a3dc8a77--