path: root/33/20c137e9e34ee9adeb1984e2b580cab977a78d

Return-Path: <bastien.teinturier@acinq.fr>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 03A3FC0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id D76698764A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:57 +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 zi3bVd34Oidb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com
 [209.85.210.46])
 by whitealder.osuosl.org (Postfix) with ESMTPS id E840B8763B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:54 +0000 (UTC)
Received: by mail-ot1-f46.google.com with SMTP id j26so1442424ots.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 01:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Tnf82TjvowDJpAmR9mGmBlB2m0CgfM/jqJK6fnwOMdA=;
 b=H9vD2/BvdJ82L4vI+KDS32JP8UuU6lHs2rnP6Fq3HDRegrKIXFpcWWBlg5SsONtUAk
 YIhf5tOpXc+hE8EgK1qg3wXDb1t8ks+wyNfe8blDTi/9Nf4xTmGWOR6ITa756nmkFzge
 hdGVgiXTIc835iHFmZ/spaRpIENg0piOLJ8JqMAirBXd2U9ax+SMncq/ADmxgk65NCBx
 YGYh36uznj6T19u1nA2xvieOpo4N3n6InEjMHB8rLvcOBVdpuXp++YQXBAt1mlBD5JPi
 iMOZv8y6jrzXsCaB0ysVTUpo44IUZcHeyeAvRhs61HBPT5lxFUS+BazMJ+qzwWjTAZLD
 c0mw==
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=Tnf82TjvowDJpAmR9mGmBlB2m0CgfM/jqJK6fnwOMdA=;
 b=CTjsyD2Wlc7UOwEwHJFt0775R6TsGL3ZSrmzx92tgPtCOz1YkddwmVziaxaaxxd2uW
 DWppANA5udx5P+KsQ1uueS95UVjbsqeohkY+yarxWzQn1SHaJ7PvXzPFfKV4EF3wHf0a
 wljhCLdODQn9bqP0O0dCiFhpMFVktxUF/Gnn6ma2r5yphG08CUcJ/Ip9e/mbuE2dA3a2
 tdWr+2CkReqKgFWO61GcR1WjZ8hAqWzQjpIdlqpKXCX5PQPSQUebLoXdaPL8gF3uAEOC
 qpRoq7pcGaOqWi4zwkOSh4aEmVsy0NHmk3LOsKSoep5qxj2oHfbVWIYK4yset6FiWByd
 tjzw==
X-Gm-Message-State: AGi0PuaAPv0Ei+9ddNU2eVyun2uEkK7pi9e/nT8NQWWHMhnIP97UUQ7x
 NV0xPFpP6xPlwB131Q9BhnCnqOSuvTXC+9RtgkzhZg==
X-Google-Smtp-Source: APiQypKpHxB9KYOAmQPFCX51sdyBvHYqGxO/Vm0AXMG4VRC3Vt+4u0GoI4xMnvt7OaC3n5c0zlT56zj0mIBi/Ett21k=
X-Received: by 2002:a9d:2c61:: with SMTP id f88mr3192711otb.86.1587545753972; 
 Wed, 22 Apr 2020 01:55:53 -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>
 <CALZpt+HFyh3X9nBvMnQ8C8T_ijahDrNsCsz0Qk_ogS5zM_BPBA@mail.gmail.com>
In-Reply-To: <CALZpt+HFyh3X9nBvMnQ8C8T_ijahDrNsCsz0Qk_ogS5zM_BPBA@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Wed, 22 Apr 2020 10:55:42 +0200
Message-ID: <CACdvm3NfHbfE1O8ajc+by0wk=tqM4L-XU0VUFD5qfxSU3ArFtQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000bb058805a3dd4c97"
X-Mailman-Approved-At: Wed, 22 Apr 2020 09:05:20 +0000
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 08:55:58 -0000

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

Hi Antoine and list,

Thanks for raising this. There's one step I'd like to understand further:

* 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.
>

Can you detail how the "absolute fee" is computed here?
Doesn't that mean that if this had a higher fee than the htlc-timeout, and
the htlc-timeout fee was
chosen to confirm quickly (that's why we have an annoying `update_fee`),
the htlc-success will confirm
quickly (which makes the problem disappear)?
Because once the commit tx is confirmed, the "package" consists of only the
htlc-success, doesn't it?

I think the devil will be in the details here, so it's worth expanding on
the fee calculation imho.

Thanks!
Bastien

Le mer. 22 avr. 2020 =C3=A0 10:01, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> 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
> 110
> * 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 i=
t
> 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 exten=
d
> 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 mempool=
s
> 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 conflictin=
g
> 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 an=
y
> critical-safety
> component in Core.
>
> A temporary fix could be to resuscitate old work to ensure peering throug=
h
> 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 lightnin=
g
> knowledge so feel free
> to verify and double-check more than usual
>
> Cheers
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/00=
2240.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
>> 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 addi=
ng
>> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pre=
tty
>> 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 signat=
ure
>> 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?")
>> > > >     =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
>> 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 usin=
g
>> 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-disabl=
ed
>> 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 mus=
t
>> 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 hashloc=
k
>> 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 bidde=
rs
>> 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 fr=
om
>> 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 i=
s
>> 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 be=
en
>> 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 eno=
ugh
>> 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-Time=
out
>> 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 wil=
l
>> happen eventually.
>> > >
>> > > * C can bribe a miner to prevent HTLC-Timeout from confirming betwee=
n
>> 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 t=
ry
>> their luck at mining and evict the censoring miner.
>> > >       * Thus, letting B bump the fee on HTLC-Timeout is precisely th=
e
>> 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, wher=
eas
>> B can offer its bribe as being something that miners can claim now witho=
ut
>> waiting after L+1.
>> > >
>> > > The issue of course is the additional output that bloats the UTXO se=
t
>> 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 fundin=
g
>> 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 transaction=
s,
>> 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
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr">Hi Antoine and list,<div><br></div><div>Thanks for raising=
 this. There&#39;s one step I&#39;d like to understand further:</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Mallory can br=
oadcast its Pinning Preimage Tx on offered HTLC #2 output on Alice&#39;s tr=
ansaction,<br>feerate is maliciously chosen to get in network mempools but =
never to confirm. Absolute fee must<br>be higher than HTLC-timeout #2, a fa=
ct known to Mallory. There is no p2p race.<br></blockquote><div><br></div><=
div>Can you detail how the &quot;absolute fee&quot; is computed here?</div>=
<div>Doesn&#39;t that mean that if this had a higher fee than the htlc-time=
out, and the htlc-timeout fee was</div><div>chosen to confirm quickly (that=
&#39;s why we have an annoying `update_fee`), the htlc-success will confirm=
</div><div>quickly (which makes the problem disappear)?</div><div>Because o=
nce the commit tx is confirmed, the &quot;package&quot; consists of only th=
e htlc-success, doesn&#39;t it?</div><div><br></div><div>I think the devil =
will be in the details here, so it&#39;s worth expanding on the fee calcula=
tion imho.</div><div><br></div><div>Thanks!</div><div>Bastien</div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
mer. 22 avr. 2020 =C3=A0=C2=A010:01, Antoine Riard &lt;<a href=3D"mailto:an=
toine.riard@gmail.com">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>Personally, I would have wait a bit before to go public on this, like=
 letting some implementations <br>increasing their CLTV deltas, but anyway,=
 it&#39;s here now.<br>=C2=A0<br>Mempool-pinning attacks were already discu=
ssed on this list [0], but what we found is you<br>can _reverse_ the scenar=
io, where it&#39;s not the malicious party delaying confirmation of honest<=
br>party transactions but malicious deliberately stucking its own transacti=
ons in the mempool to avoid<br>confirmation of timeout. And therefore gamin=
g inter-link timelock to provoke an unbalanced<br>settlement 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 leverage mempool rul=
es 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<br>transaction be=
ing bounce off due to your transaction being already there.<br><br>Beyond d=
isabling RBF on your transaction (with current protocol, not anchor proposa=
l), there is<br>two likely candidates:<br>* BIP 125 rule 3: &quot;The repla=
cement transaction pays an absolute fee of at least the sum paid by the ori=
ginal transactions.&quot;<br>* BIP 125 rule 5: &quot;The number of original=
 transactions to be replaced and their descendant transactions which will b=
e evicted from the mempool must not exceed a total of 100 transactions.&quo=
t;<br><br>Let&#39;s go through whole scenario:<br>* Mallory and Eve are col=
luding<br>* Eve and Mallory are opening channels with Alice, Mallory do a b=
it of rebalancing<br>to get full incoming capacity, like receiving funds on=
 an onchain address through another Alice<br>link<br>* Eve send a HTLC #1 t=
o Mallory through Alice expirying at block 100<br>* Eve send a second HTLC =
#2 to Mallory through Alice, expirying at block 110 on outgoing link<br>(A&=
lt;-&gt;M), 120 on incoming link (E&lt;-&gt;A)<br>* Before block 100, witho=
ut cancellation from Mallory, Alice will force-close channel 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<b=
r>* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output=
 on Alice&#39;s transaction,<br>feerate is maliciously chosen to get in net=
work mempools but never to confirm. Absolute fee must<br>be higher than HTL=
C-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 going to broadcast =
HTLC-timeout #2, feerate may be higher but as absolute<br>fee is lower, it&=
#39;s going to be rejected from network mempools as replacement for Pinning=
 Preimage<br>Tx (BIP 125 rule 3)<br>* At block 120, Eve closes channel and =
HTLC-timeout HTLC #2<br>* Mallory can RBF its Pinning Preimage Tx by a high=
-feerate one and get it confirmed<br><br>New anchor_output proposal, by dis=
abling 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 &quo=
t;pinning<br>lease&quot; by ejecting your malicious tx, like conflicting or=
 trimming out of the mempool one of its<br>parents. And then reannounce you=
r preimage tx with a lower-feerate-but-still-high-fee before a<br>new block=
 and a honest HTLC-timeout rebroadcast.<br><br>AFAICT, even with anchor_out=
put deployed, even assuming empty mempools, success rate and economic<br>ra=
tionality of attacks is finding such cheap, reliable &quot;pinning lease ex=
tension&quot; trick.<br><br>I think any mempool watching mitigation is at b=
est a cat-and-mouse hack. Contrary to node <br>advancing towards a global b=
lockchain view thanks to PoW, network mempools don&#39;t have a convergence=
<br>guarantee. This means, =C2=A0in a distributed system like bitcoin, node=
 don&#39;t see events in the same<br>order, Alice may observe tx X, tx Y, t=
x Z and Bob may observe tx Z, tx X, tx Y. And order of events<br>affects if=
 a future event is going to be rejected or not, like if tx Z disable-RBF an=
d tx X try to<br>replace Z, Alice accepts X and Bob rejects it. And this di=
vergence may perserve until a new block.<br><br>Practically, it means an at=
tacker can provoke a local conflict to bounce off HTLC preimage tx out <br>=
of your mempool while broadcasting preimage tx without conflict to the rest=
 of the network by<br>tweaking tx-relay protocol and so easily manipulating=
 order of events for every node. A local<br>conflict is easy to provoke, ju=
st make tx A double-spent by both HTLC-preimage-tx and non-RBF-tx-B.<br>Ann=
ounce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of network=
. When rest of <br>network announce HTLC-preimage-tx, it&#39;s going to rej=
ected by your mempool.<br><br>Provoking local conflict assumes of course _i=
nterlayer_ mapping by an attacker, i.e mapping your LN<br>node to your full=
-node(s). Last time, we check, there was 982 match by IP for 4,500 LN/52,00=
0<br>full-node. Mapping heuristics is an ongoing research subject 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>feerate as everything=
 is attacker malleable b) you may want to catch tx and extract preimage<br>=
on the p2p wire, but processing raw transaction would be such a DoS vector.=
..<br><br>Overall, I think we all agree on the long term direction to get a=
 Contracting-Protocols-Enhanced<br>mempool with a multiparty-safe-API, bund=
led with package relay deployment. Even if there is current<br>move toward =
this direction, this may take longer than expected as with any critical-saf=
ety<br>component in Core.<br><br><div>A temporary fix could be to resuscita=
te old work to ensure peering through a full-RBF propagation path,</div><di=
v>but p2p implications are hard to gauge, like wouldn&#39;t guarantee p2p c=
ensorship resistance of this...<br></div><br></div><div>It&#39;s quite a ta=
ngled issue, with a good deal of both bitcoin and lightning knowledge so fe=
el free</div><div>to verify and double-check more than usual<br></div><div>=
<br>Cheers<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/lightning-dev/2019-October/002240.html" target=3D"_blank">https://lists.l=
inuxfoundation.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_=
attr">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" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-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>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--000000000000bb058805a3dd4c97--