path: root/6c/fbab6c682cc9347565ddad6af67a8920152b9e

Return-Path: <antoine.riard@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B0754C016E;
 Mon, 29 Jun 2020 00:13:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id AB6E388C5B;
 Mon, 29 Jun 2020 00:13:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id D-fKS8bgtRne; Mon, 29 Jun 2020 00:13:19 +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-lj1-f194.google.com (mail-lj1-f194.google.com
 [209.85.208.194])
 by hemlock.osuosl.org (Postfix) with ESMTPS id BF66988C33;
 Mon, 29 Jun 2020 00:13:18 +0000 (UTC)
Received: by mail-lj1-f194.google.com with SMTP id b25so12495421ljp.6;
 Sun, 28 Jun 2020 17:13:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=IYBWA9jdI3WpSyl+r8ysP7wZhrH0guHb0O6CF6p8k6k=;
 b=mHcHE7OsHQ8uKg9oFWyXsUisaiLF8QcXFHzA4OJTd1IBEakqDtvrfWfkNXTInEVQXw
 2zWwmRD5uYL/2bijJ41D91G4EDqUP0Y6F+QgcCIvHNYPn65pZLW2im/vydtbLxH6n3SM
 kcYYIgEyR8kMWEbby5+PEQY/CAc3POk/0KOUKhOBQJA6I01v2RP6pxnZQr5iurZXOGCQ
 neD+Cd0SU2XGKGQUk0AdTKaNZyo4OQd4EWOZYkHS8G3uyTU4GaS0OshNsgZq5xNWUc+8
 84rpdD/5OOkCF5qwPGgyt9SPzuwG2Lyoqg4J7mgpD43EyofAZdf087+IbLfrrQrGN7x9
 QOQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=IYBWA9jdI3WpSyl+r8ysP7wZhrH0guHb0O6CF6p8k6k=;
 b=HsNysVccqRQcZcNAeLICCsnTuhocnjqcdj1HBR5FD+qypyZEJOHFXOA+2uNCTV7yu1
 VsERgDwQLjfmdHoL1awsezf5dfsEP4Rd6nJ4M9w1iwwHnEnRrVLhTN187cB+h9+Bl4mL
 mMfR+BUvJDaYy6GjAJV03dDbJNf9P/vuQy33AiM0nbtbrxc6K/TmjwCBKfPSYVi7OnlI
 RaHvr7vU6CGJTkuYKnD2O18TRypoHxJpCd5xMLBuboR5mqhk2V8y8oZAs23dmYBY33Q+
 8loxl6xX8rDGJEiX2OMHD/Tyaw2fAOP8H1DlFHrCUiErirEaro6mWeOuSS2/zSc3FB3C
 q6hA==
X-Gm-Message-State: AOAM531t+AUZRs0TIBFgPqPZp66mDWi5aLFvli5B99RYWqPtXNxKo/j8
 pUD3eraltSnaFYEzUGRePqlnbjRNV8U/zkWKhnnypsXg
X-Google-Smtp-Source: ABdhPJyzunfzqnBGAeKZQkLbuqSC98Ay04IUqPMgO2XGL/t7ns9CQRov10i42cygJmBfhl5zP898Y/WYbKpdLenZGlI=
X-Received: by 2002:a2e:854c:: with SMTP id u12mr6296480ljj.352.1593389596111; 
 Sun, 28 Jun 2020 17:13:16 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 28 Jun 2020 20:13:03 -0400
Message-ID: <CALZpt+Ea=GyzEAfJBZzdFvus4_U=x73eA+=J=sN2LONq9_V5dw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dd76f605a92decec"
X-Mailman-Approved-At: Mon, 29 Jun 2020 00:27:22 +0000
Subject: [bitcoin-dev] Pinning : The Good, The Bad, The Ugly
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: Mon, 29 Jun 2020 00:13:21 -0000

--000000000000dd76f605a92decec
Content-Type: text/plain; charset="UTF-8"

(tl;dr Ideally network mempools should be an efficient marketplace leading
to discovery of best-feerate blockspace demand by miners. It's not due to
current anti-DoS rules assumptions and it's quite harmful for shared-utxo
protocols like LN)

Hello all,

Lightning security model relies on the unilateral capability for a channel
participant to confirm transactions, like timing out an outgoing HTLC,
claiming an incoming HTLC or punishing a revoked commitment transaction and
thus enforcing onchain a balance negotiated offchain. This security model
is actually turning back the double-spend problem to a private matter,
making the duty of each channel participant to timely enforce its balance
against the competing interest of its counterparties. Or laid out
otherwise, contrary to a miner violating a consensus rules, base layer
peers don't care about your LN node failing to broadcast a justice
transaction before the corresponding timelock expiration (CSV delay).

Ensuring effective propagation and timely confirmation of LN transactions
is so a critical-safety operation.  Its efficiency should be always
evaluated with regards to base layer network topology, tx-relay propagation
rules, mempools behaviors, consistent policy applied by majority of nodes
and ongoing blockspace demand. All these components are direct parameters
of LN security. Due to the network being public, a malicious channel
counterparty do have an incentive to tweak them to steal from you.

The pinning attacks which have been discussed since a few months are a
direct illustration of this model. Before digging into each pinning
scenario, few properties of the base layer components should be evocated
[0].

Network mempools aren't guaranteed to be convergent, the local order of
events determines the next events accepted. I.e Alice may observe tx X, tx
Y, tx Z and Bob may observe tx Z, tx X, tx Y. If tx Z disable-RBF and tx X
try to replace Z, Alice accepts X and Bob rejects it. This divergence may
persevere until a new block.

Tx-relay topology can be observed by spying nodes [1]. An attacker can
exploit this fact to partition network mempools in different subset and
hamper propagation across them of same-spending output concurrent
transactions. If subset X observes Alice commitment transaction and subset
Y observes Bob commitment transaction, Alice's HTLC-timeout spending her
commitment won't propagate beyond the X-Y set boundaries. An attacker can
always win the propagation race through massive connections or bypassing
tx-relay privacy timers.

Miners mempools are likely identifiable, you could announce a series of
conflicting transactions to different subsets of the network and observe
"tainted" block composition to assign to each subset a miner mempool. I'm
not aware of any research on this, but it sounds plausible to identify all
power-miner mempool, i.e the ones likely to mine a block during the block
delay of the timelock you're looking to exploit. If you can't bid a
transaction in such miner mempools your channel state will stale and your
funds may be in danger.

### Scenario 1) HTLC-Preimage Pinning

As Matt previously explained in his original mail on RBF-pinning, a
malicious counterparty has an interest to pin a low-feerate HTLC-preimage
transaction in some network mempools and thus preventing a honest
HTLC-timeout to confirm. For details, refer to Optech newsletter [2].

This scenario doesn't bear any risk to the attacker, is easy to execute and
has double-digit rate of success. You don't assume network topologies
manipulation, mempools partitions or LN-node-to-full-node mapping [3] That
said this should be solved by implementing and deploying anchor outputs,
which effectively allows a party to unilaterally bump feerate of its
HTLC-timeout transactions.

### The Anchor Output Proposal

Anchor Output proposal is a current spec object implemented by the LN dev
community, it introduces the ability to _unilaterally_ and _dynamically_
bump feerate of any commitment transaction. It also opened the way to bump
local 2nd-stage transactions.

Beyond solving scenario 1), it makes LN node safe with regards to
unexpected mempool congestion. If your commitment transaction is stucking
in network mempools you can bump its feerate by attaching a CPFP on the new
`to_local` anchor. If the remote commitment gets stuck in network mempools,
you're able to bump it by attaching a CPFP on the `to_remote` anchor. This
should keep your safe against an unresponsive or lazy counterparty in case
of onchain funds to claim.

IMO, it comes with a trade-off as it introduces a mapping oracle, i.e a
linking vector between a LN node and its full-node. In this case, a spying
node may establish a dummy, low-value channel with a probed LN node, break
it by broadcasting thousands of different versions of the (revoked)
commitment and observes which one broadcast a CPFP first on the p2p layer.
Obviously, you can mitigate it by not chasing after low-value HTLC, but
that is a small risk of money loss. As of today,  this oracle can be seen
as acceptable as we have other ones and we may get rid of it in the future.

### Scenario 2a) Revoked Commitment Transaction Pinning

Digging further, we found that there are more concerning scenarios of
pinning, at the commitment-tx level. At a period of low-feerate, a
malicious party incessantly updates a channel until to obtain ~10k revoked
commitment transactions.

At a period of mempool-congestion, by having setup a fine-grained
`dust_limit_satoshis` and at same-time circulary routing HTLCs, our
malicious party can inflate absolute fee of its own commitment bounded
while breaking channel in the middle of an update sequence, ensuring it has
a higher-fee than the commitment of the honest counterparty. As channel
opener, the attacker has the amplitude of malleating the victim's
commitment such to keep it equal or under revoked feerate.

Then our malicious party broadcast to each base layer public peer one of
the revoked commitment transactions, that way partitioning the network
mempools in 10k subset. Even assuming anchor output a honest LN node won't
be able to confirm the remote commitment through a CPFP, this one failing
to cross subset boundaries, the parent txid being different at each.

Broadcasting the honest commitment transaction will fail, its feerate being
known and malleable it won't RBF already-in-mempool remote commitment
transactions. This prevents an honest party to timely timeout an outgoing
HTLC or an incoming HTLC.

This scenario does bear a low-risk to the attacker, is easy to execute and
has a likely double-digit rate of success once you tune feerate
malleability. You assume mempools partitions but not any network topologies
discovery. We underscore there is no current p2p/mempool mechanism to learn
about conflicting transactions, even learning about near-topology conflicts
don't guarantee you that a propagation path is uniform to make your CPFP
successful.

### Scenario 2b) Previous-Latest Commitment Transaction Pinning

A variant of commitment-tx pinning is to rely only on valid commitment
transactions. Channel update sequence not being atomic, you can legally own
2 valid commitment transactions. An attacker can successfully map a
LN-node's full-node and such, announce one of them and the other one to the
rest of the network. A honest peer will fail to leverage the `to_remote`
anchor output as its CPFP won't propagate again over network mempools
partitions.

This scenario doesn't bear a risk to the attacker, is medium to execute and
has a likely double-digit rate of success. You assume mempools partitions
and inter-layer mapping. How hard is it to map a LN-node to a full-node ?
Actually you can use the fact that a LN-node's full-node is monitoring the
mempool for a preimage of interest and observe the announcement of such
preimage on the offchain layer. As post-anchor HTLC-Success transactions
are malleable you can once again create mass-conflicts to isolate the
full-node and improve the probe with high certainty.

### Where Package Relay helps

Solving scenario 2a) and 2b) in the most efficient way is likely to require
package relay support on the Core side. Package relay would extend the
notion of a mempool package (topologically ordered bundles of transactions)
to introduce a new class of p2p traffic. So far its implementation has been
delayed due to refactoring mempool internals, ensuring a DoS-robust design
and a p2p PR pipeline already congested.

Once deployed, a LN node would be able to join a commitment transaction and
a CPFP together and make them evaluated atomically by network mempools such
to evict any malicious remote commitment assuming a higher feerate.

### Scenario 3) Network-Topology-Aware Pinning for Propagation Obstruction

Let's assume the following base layer tx-relay topology:

                Alice ---> Bob ---> Caroll

Alice wants to send her package relay to Caroll the miner to get her
commitment transaction confirmed. A malicious counterparty could throw
remote commitment W in Bob mempool and remote commitment X in Caroll
mempool. Transaction W would be attached to a high-fee CPFP Y. Transaction
X would be attached to a low-fee CPFP Z such that X pins in Caroll mempool.
CPFP Y and CPFP Z would be crafted such as both incorporating a conflicting
parent to prevent Bob and Caroll mempool convergence. It looks like the
following:

Bob's mempool:
tx W ---> tx Y
parent 1 ---> tx Y

Caroll's mempool:
tx X ---> tx Z
parent 2 ---> tx Z

Bob's mempool would announce and send package "tx W + tx Y + parent 1" to
Caroll's one and due to parent 1 and parent 2 spending the same output
package would be rejected. High-fee package W will prevent Alice to
successfully broadcast her package to Caroll. This fee can be higher than
the maximum one that Alice would pay to confirm her transaction, as due to
conflicts, it won't be _effectively_ paid by the malicious counterparty.

This scenario does bear a risk to the attacker only if miner mempools
haven't been well-mapped and high-fee package leak into them, is hard to
execute but has a likely double-digit rate of success. It assumes mempool
partitions, network topology knowledge and inter-layer mapping.

### Current Mempool Design Flaws in the lights of Contracting Applications
with Competing Interests

Scenario 3) does illustrate a current flaw of mempool with regards to
contracting applications with competing interests. A counterparty can
leverage network propagation rules to prevent miners' mempools to discover
the best feerate package and thus not having to pay the real fee price to
successfully obstrucate broadcast of honest package relay spending the same
output.

These network propagation rules, namely RBF opt-in, have been designed to
protect network mempools against any DoS but don't protect a single-party
against its shared-utxo co-owners. Amending these rules to enable
mempool-convergence based on feerate will enable a honest bid market for
contracting applications and ensure network-wise higher feerate. Getting
this right will require significant study as you may allow total mempool
fees to decrease when the transactions are near the bottom of the mempool.
At first sight, it sounds incentives-compatible, as miner a) gets the
highest fee bid b) an attacker does have to compete on feerate to attempt
stealing.

Assuming a basic package relay to evict low-feerate malicious commitment,
an alternative proposal could be to introduce outbound tx-relay peers
rotation to sweep and reach ~80% of the network in less than HTLC
timelocks.  Your LN node's full node will _probabilistically_ connect to a
miner mempool and announce to it the best feerate package. Making the
tx-relay topology more dynamic would make it harder for an attacker to make
package obstruction effective. IMHO, it sounds easier on the
engineering-side, but likely worse for privacy due to the aggressive
broadcast pattern.

Another alternative could be to have more ad hoc privacy-preserving
redundant tx-broadcast.

A fourth proposal, Matt's one, is to design some blind-CPFP package relay
with a pointer to original funding outpoint to rebind on-the-flight but it
does assume noinput.

### Conclusion

To the best of my knowledge, assuming mempools congestion levels we have
seen in the past months, currently deployed LN peers aren't secure against
scenario 2a) and 2b) to any motivated attackers with a decent knowledge of
both layers. Further, ensuring scenario 3) security requires heavy,
long-term work at the base layer.

IMO, we should a) go forward with anchor proposal implementation, it comes
with trade-off but enables mempool-congestion safety, b) work on package
relay to solve commitment-level pinning, c) study best base layer mechanism
to ensure best feerate package discovery by any miner's mempools and d) in
the meanwhile increase delta and deadline timelocks.

Thoughts ?

Thanks to Matt and t-bast for conversations.

Cheers,

Antoine

[0] For newcomers, see also t-bast's great piece on LN's transactions :
https://github.com/t-bast/lightning-docs/blob/master/lightning-txs.md

[1] And current state of opinions is obfuscating tx-relay topology is a
hard problem
https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-480398802

[2]
https://bitcoinops.org/en/newsletters/2020/04/29/#new-attack-against-ln-payment-atomicity

[3] Obviously all these scenarios do have a setup cost scoping channel
opening onchain fees and
rebalancing but it's order(s) of magnitude lower if you can steal from
meaningful channels.

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

<div dir=3D"ltr">(tl;dr Ideally network mempools should be an efficient mar=
ketplace leading to discovery of best-feerate blockspace demand by miners. =
It&#39;s not due to current anti-DoS rules assumptions and it&#39;s quite h=
armful for shared-utxo protocols like LN)<br><div><br>Hello all,<br><br><di=
v>Lightning security model relies on the unilateral capability=20
for a channel participant to confirm transactions, like timing out an=20
outgoing HTLC, claiming an incoming HTLC or punishing a revoked=20
commitment transaction and thus enforcing onchain a balance negotiated=20
offchain. This security model is actually turning back the double-spend=20
problem to a private matter, making the duty of each channel participant
 to timely enforce its balance against the competing interest of its=20
counterparties. Or laid out otherwise, contrary to a miner violating a=20
consensus rules, base layer peers don&#39;t care about your LN node failing=
=20
to broadcast a justice transaction before the corresponding timelock=20
expiration (CSV delay).<br><br>Ensuring effective propagation and timely
 confirmation of LN transactions is so a critical-safety operation.=C2=A0 I=
ts efficiency should be always evaluated with regards
 to base layer network topology, tx-relay propagation rules, mempools=20
behaviors, consistent policy applied by majority of nodes and ongoing=20
blockspace demand. All these components are direct parameters of LN=20
security. Due to the network being public, a malicious channel=20
counterparty do have an incentive to tweak them to steal from you.<br><br>T=
he
 pinning attacks which have been discussed since a few months are a=20
direct illustration of this model. Before digging into each pinning=20
scenario, few properties of the base layer components should be evocated [0=
].<br><br>Network mempools aren&#39;t guaranteed to be convergent, the loca=
l=20
order of events determines the next events accepted. I.e Alice may=20
observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X, tx Y. If tx Z=20
disable-RBF and tx X try to replace Z, Alice accepts X and Bob rejects=20
it. This divergence may persevere until a new block.<br><br>Tx-relay=20
topology can be observed by spying nodes [1]. An attacker can exploit=20
this fact to partition network mempools in different subset and hamper=20
propagation across them of same-spending output concurrent transactions. If=
 subset X
 observes Alice commitment transaction and subset Y observes Bob=20
commitment transaction, Alice&#39;s HTLC-timeout spending her commitment=20
won&#39;t propagate beyond the X-Y set boundaries. An attacker can always w=
in the propagation race through massive connections or bypassing tx-relay p=
rivacy timers.<br><br>Miners mempools=20
are likely identifiable, you could announce a series of conflicting=20
transactions to different subsets of the network and observe &quot;tainted&=
quot;=20
block composition to assign to each subset a miner mempool. I&#39;m not=20
aware of any research on this, but it sounds plausible to identify all=20
power-miner mempool, i.e the ones likely to mine a block during the=20
block delay of the timelock you&#39;re looking to exploit. If you can&#39;t=
 bid a transaction in such miner mempools your channel state will stale and=
 your funds may be in danger.<br><br>### Scenario 1) HTLC-Preimage Pinning<=
br><br>As
 Matt previously explained in his original mail on RBF-pinning, a=20
malicious counterparty has an interest to pin a low-feerate=20
HTLC-preimage transaction in some network mempools and thus preventing a
 honest HTLC-timeout to confirm. For details, refer to Optech newsletter
 [2].<br><br>This scenario doesn&#39;t bear any risk to the attacker, is=20
easy to execute and has double-digit rate of success. You don&#39;t assume=
=20
network topologies manipulation, mempools partitions or=20
LN-node-to-full-node mapping [3] That said this should be solved=20
by implementing and deploying anchor outputs, which effectively allows a
 party to unilaterally bump feerate of its HTLC-timeout transactions.<br><b=
r>### The Anchor Output Proposal <br><br>Anchor
 Output proposal is a current spec object implemented by the LN dev=20
community, it introduces the ability to _unilaterally_ and=20
_dynamically_ bump feerate of any commitment transaction. It also opened
 the way to bump local 2nd-stage transactions.<br><br>Beyond solving=20
scenario 1), it makes LN node safe with regards to unexpected mempool=20
congestion. If your commitment transaction is stucking in network mempools =
you can bump its feerate by attaching a CPFP on the new `to_local` anchor. =
If the remote commitment gets stuck in network mempools, you&#39;re able to=
 bump it by attaching a CPFP on the `to_remote` anchor. This should keep yo=
ur safe against an unresponsive or lazy counterparty in case of onchain fun=
ds to claim.<br></div><div><br>IMO, it comes with
 a trade-off as it introduces a mapping oracle, i.e a linking vector betwee=
n a LN node and its full-node. In this case, a spying node may establish a =
dummy, low-value channel with a probed LN node, break it by broadcasting th=
ousands of different versions of the (revoked) commitment and observes whic=
h one broadcast a CPFP first on the p2p layer. Obviously, you can mitigate =
it by not chasing after low-value HTLC, but that is a small risk of money l=
oss. As of today,=C2=A0 this oracle can be seen as=20
acceptable as we have other ones and we may get rid of it in the future.<br=
><br>### Scenario 2a) Revoked Commitment Transaction Pinning<br><br>Digging
 further, we found that there are more concerning scenarios of pinning,=20
at the commitment-tx level. At a period of low-feerate, a malicious=20
party incessantly updates a channel until to obtain ~10k revoked=20
commitment transactions.<br><br>At a period of mempool-congestion, by=20
having setup a fine-grained `dust_limit_satoshis` and at same-time=20
circulary routing HTLCs, our malicious party can inflate absolute fee of
 its own commitment bounded while breaking channel in the middle of an=20
update sequence, ensuring it has a higher-fee than the commitment of the
 honest counterparty. As channel opener, the attacker has the amplitude of =
malleating the victim&#39;s commitment such to keep it equal or under revok=
ed feerate.<br><br>Then our malicious party broadcast to each=20
base layer public peer one of the revoked commitment transactions,=20
that way partitioning the network mempools in 10k subset. Even assuming=20
anchor output a honest LN node won&#39;t be able to confirm the remote=20
commitment through a CPFP, this one failing to cross subset boundaries,=20
the parent txid being different at each.<br><br>Broadcasting the honest=20
commitment transaction will fail, its feerate being known and malleable=20
it won&#39;t RBF already-in-mempool remote commitment transactions. This=20
prevents an honest party to timely timeout an outgoing HTLC or an=20
incoming HTLC.<br><br>This scenario does bear a low-risk to the=20
attacker, is easy to execute and has a likely double-digit rate of=20
success once you tune feerate malleability. You assume mempools=20
partitions but not any network topologies discovery. We underscore there is=
 no current p2p/mempool mechanism to learn about conflicting transactions, =
even learning about near-topology conflicts don&#39;t guarantee you that a =
propagation path is uniform to make your CPFP successful.<br><br>### Scenar=
io 2b) Previous-Latest Commitment Transaction Pinning<br><br>A
 variant of commitment-tx pinning is to rely only on valid commitment=20
transactions. Channel update sequence not being atomic, you can legally=20
own 2 valid commitment transactions. An attacker can successfully map a=20
LN-node&#39;s full-node and such, announce one of them and the other one to=
=20
the rest of the network. A honest peer will fail to leverage the=20
`to_remote` anchor output as its CPFP won&#39;t propagate again over networ=
k=20
mempools partitions.<br><br>This scenario doesn&#39;t bear a risk to the=20
attacker, is medium to execute and has a likely double-digit rate of=20
success. You assume mempools partitions and inter-layer mapping. How=20
hard is it to map a LN-node to a full-node ? Actually you can use the=20
fact that a LN-node&#39;s full-node is monitoring the mempool for a preimag=
e
 of interest and observe the announcement of such preimage on the=20
offchain layer. As post-anchor HTLC-Success transactions are malleable=20
you can once again create mass-conflicts to isolate the full-node and=20
improve the probe with high certainty.<br><br>### Where Package Relay helps=
 <br><br>Solving
 scenario 2a) and 2b) in the most efficient way is likely to require=20
package relay support on the Core side. Package relay would extend the=20
notion of a mempool package (topologically ordered bundles of transactions)=
 to introduce a new
 class of p2p traffic. So far its implementation has been delayed due to
 refactoring mempool internals, ensuring a DoS-robust design and a p2p PR p=
ipeline already congested. <br><br>Once
 deployed, a LN node would be able to join a commitment transaction and a
 CPFP together and make them evaluated atomically by network mempools=20
such to evict any malicious remote commitment assuming a higher feerate.<br=
><br>### Scenario 3) Network-Topology-Aware Pinning for Propagation Obstruc=
tion<br><br>Let&#39;s assume the following base layer tx-relay topology:<br=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alice ---&gt; =
Bob ---&gt; Caroll<br><br>Alice
 wants to send her package relay to Caroll the miner to get her
commitment transaction confirmed. A malicious counterparty could throw=20
remote commitment W in Bob mempool and remote commitment X in Caroll=20
mempool. Transaction W would be attached to a high-fee CPFP Y.=20
Transaction X would be attached to a low-fee CPFP Z such that X pins in=20
Caroll mempool. CPFP Y and CPFP Z would be crafted such as both=20
incorporating a conflicting parent to prevent Bob and Caroll mempool=20
convergence. It looks like the following:<br><br></div><div>Bob&#39;s mempo=
ol:<br></div><div>tx W ---&gt; tx Y</div><div>parent 1 ---&gt; tx Y</div><d=
iv><br></div><div>Caroll&#39;s mempool:</div><div>tx X ---&gt; tx Z</div><d=
iv>parent 2 ---&gt; tx Z<br><br></div><div>Bob&#39;s mempool would announce=
 and send package &quot;tx W + tx Y + parent 1&quot; to Caroll&#39;s one an=
d due to parent 1 and parent 2 spending the same output package would be re=
jected. High-fee package W will prevent Alice to=20
successfully broadcast her package to Caroll. This fee can be higher=20
than the maximum one that Alice would pay to confirm her transaction, as
 due to conflicts, it won&#39;t be _effectively_ paid by the malicious coun=
terparty.<br><br>This
 scenario does bear a risk to the attacker only if miner mempools haven&#39=
;t been well-mapped and high-fee package leak into them, is hard to execute=
 but has a likely double-digit rate
 of success. It assumes mempool partitions, network topology knowledge=20
and inter-layer mapping.<br><br>### Current Mempool Design Flaws in the lig=
hts of Contracting Applications with Competing Interests<br><br>Scenario
 3) does illustrate a current flaw of mempool with regards to=20
contracting applications with competing interests. A counterparty can=20
leverage network propagation rules to prevent miners&#39; mempools to=20
discover the best feerate package and thus not having to pay the real=20
fee price to successfully obstrucate broadcast of honest package relay=20
spending the same output.<br><br>These network propagation rules, namely
 RBF opt-in, have been designed to protect network mempools=20
against any DoS but don&#39;t protect a single-party against its shared-utx=
o
 co-owners. Amending these rules to enable mempool-convergence based on=20
feerate will enable a honest bid market for contracting applications and
 ensure network-wise higher feerate. Getting this right will require signif=
icant study as you may allow total mempool fees to decrease when the transa=
ctions are near the bottom of the mempool. At first sight, it sounds incent=
ives-compatible, as miner a) gets the highest fee bid b) an attacker does h=
ave to compete on feerate to attempt stealing. <br></div><div><br></div><di=
v>Assuming a basic package relay to evict low-feerate malicious commitment,=
 an alternative proposal could be to introduce outbound tx-relay peers rota=
tion to sweep and reach ~80% of the network in less than HTLC timelocks.=C2=
=A0 Your LN node&#39;s full node will _probabilistically_ connect to a mine=
r mempool and announce to it the best feerate package. Making the tx-relay =
topology more dynamic would make it harder for an attacker to make package =
obstruction effective. IMHO, it sounds easier on the engineering-side, but =
likely worse for privacy due to the aggressive broadcast pattern.<br><br></=
div><div>Another alternative could be to have more ad hoc privacy-preservin=
g redundant tx-broadcast.<br><br></div><div>A fourth proposal, Matt&#39;s o=
ne, is to design some blind-CPFP package relay with a pointer to original f=
unding outpoint to rebind on-the-flight but it does assume noinput.<br></di=
v><div><br>### Conclusion<br></div><div><br>To the
 best of my knowledge, assuming mempools congestion levels we have seen in
the past months, currently deployed LN peers aren&#39;t secure against=20
scenario 2a) and 2b) to any motivated attackers with a decent knowledge=20
of both layers. Further, ensuring scenario 3) security requires heavy,=20
long-term work at the base layer.<br><br>IMO, we should a) go forward with =
anchor proposal implementation, it comes with trade-off but enables mempool=
-congestion safety, b) work on package relay to solve commitment-level pinn=
ing, c) study best base layer mechanism to ensure best feerate package disc=
overy by any miner&#39;s mempools and d) in the meanwhile increase delta an=
d deadline timelocks.<br><br></div><div>Thoughts ?<br></div><div><br></div>=
<div>Thanks to Matt and t-bast for conversations.<br></div><div><br>Cheers,=
<br><br>Antoine <br></div><div><br></div><div>[0] For newcomers, see also t=
-bast&#39;s great piece on LN&#39;s transactions : <a href=3D"https://githu=
b.com/t-bast/lightning-docs/blob/master/lightning-txs.md">https://github.co=
m/t-bast/lightning-docs/blob/master/lightning-txs.md</a></div><div><br>[1] =
And current state of opinions is obfuscating tx-relay topology is a hard pr=
oblem <br><a href=3D"https://github.com/bitcoin/bitcoin/pull/15759#issuecom=
ment-480398802" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/1=
5759#issuecomment-480398802</a><br><br>[2] <a href=3D"https://bitcoinops.or=
g/en/newsletters/2020/04/29/#new-attack-against-ln-payment-atomicity" targe=
t=3D"_blank">https://bitcoinops.org/en/newsletters/2020/04/29/#new-attack-a=
gainst-ln-payment-atomicity</a><br><br>[3] Obviously all these scenarios do=
 have a setup cost scoping channel opening onchain fees and<br>rebalancing =
but it&#39;s order(s) of magnitude lower if you can steal from meaningful c=
hannels.</div></div></div>

--000000000000dd76f605a92decec--