Hi list,

Security and operations of higher-layer protocols (vaults, LN, CoinJoin, watchtowers, ...) come with different assumptions and demands with regards to tx-relay and fee models. As the Bitcoin stack is quite young, it would be great to make those ones more understood and what p2p/mempool changes we might adopt at the base layer to better answer them. I would like to explore this with my current post.

### Time-Sensitive Protocols Security-Model (you can skip this if you know LN)

Lightning, the most deployed time-sensitive protocol as of now, relies on the timely confirmations of some of its transactions to enforce its security model. Like timing out an outgoing HTLC, claiming an incoming HTLC or punishing a revoked commitment. Ensuring timely confirmation is two-fold: a) propagating well-transactions across the network to quickly hit miner mempools b) offering a competitive feerate to get in next coming blocks.

Updating feerate just-in-time is quite challenging for LN as you can't resign a commitment once your counterparty is non-responsive or malicious, and thus any fee strategy assuming interactivity is closed. With current constraints of maintaining a trustless chain of transactions (no Parent-Pay-For-Child), the only option is a CPFP. Ongoing update of LN protocol (anchor-outputs) will allow a channel participant to unilaterally bump feerate of its commitment/HTLCs txn, assuming there is no _adversarial_ network mempool conditions like a concurrent broadcast.

Beyond enforcing the need to secure its funds by bumping feerate, an offchain user might be willingly to accelerate confirmation of a broadcast for liquidity management in face of mempool-congestion. This issue is likely shared by any multi-party protocol like Coinjoins where resigning is painful and a party may have different liquidity preferences than other participants and would like to express them in an unilateral fee bumping.

### Effective Transaction Propagation and Uniform Relay Policy

Even before competing on feerate, the first and foremost point of the laid-out security model was the well-propagation of transactions across the p2p network. Its effectiveness is determined by compliance to 1) consensus rules 2) policy rules. This second set is a tighter one governing different aspects of your transactions (like size, output type, feerate, ancestors/descendants, ...) and introduced to sanitize the p2p network against a wide scope of resources abuses (RBF bandwidth waste, package evaluation CPU DoS, economic nonsense outputs, ...)

These rules diverge across implementations/versions and a subset of them can be tightened or relaxed by node operators. This heterogeneity is actually where the risk is scored for higher protocols, your LN's full-node might be connected to tx-relay peers with more constraining policies than yours and thus will always reject your time-sensitive transactions, silently breaking security of your channels [0].

Of course, LN protocols devs have always been aware of these issues and carefully reflect policies enforcement in their codebase. That said an important subset of them aren't documented or even standardized and thus hard to incorporate in upper layers specs. Testing them in a black box approach (i.e `testmempoolaccept`) before production doesn't work as your broadcast has to be valid against the union of your yet-unknown tx-relay topology, further static checks are blurred with dynamic ones (the feerate now is different than the one at a future broadcast), and your transaction might be malleate by your counterparty (like a ridiculous feerate).

And the other side, AFAIK, Core developers have always acknowledged these issues and been really conscientious when updating such API policy. The concerning change with protocol like LN is the severity consequences in case of incompatible changes. Previously, your basic transaction would have been rejected by the network and your application could have been updated before successfully rebroadcasting. Now, such changes potentially outlawing your time-sensitive broadcasts is a direct, measurable risk of fund loss, either triggered by mempool-congestion or exploited by a malicious counterparty.

Therefore, moving towards such stable tx-relay/bumping API, I propose:
a) Identifying and documenting the subset of policy rules on which upper layers have to rely on to enforce their security model
b) Guaranteeing backward-compatibility of those rules or, in case of tightening change, making sure there is ecosystem coordination with some minimal warning period (1 release ?)

Committing to a uniform policy would be a philosophical change, it would ossify some parts of full-node implementations. Another side-effect means that upper layer devs would be incentivized to rely on such stable API. In case of new DoS on the base layer, we might have to tighten them in a short timeline at the price of breaking some offchain applications [1] On the other side, full-node operators have an interest to follow such uniform policy, as it would improve the effective feerate discovery by their mempools.

### Adversarial Fee Bumping and Package Relay

Assuming anchor-output gets adopted & deployed, even beyond LN, it doesn't guarantee success of CPFP, where success is defined as letting know the network mempools of your fee-bid, confirmation being always a function of concurrent fee-bids from other users. Indeed, if it allows bump at the transaction-level, there is no guarantee of enforcement at the tx-relay layer. Mempool acceptance for any transaction is done on its own, a low-feerate parent can be rejected while a high-feerate child might have to follow fews microseconds later.

This has consequences both for network nodes, the ones with small mempools won't discover the best feerate bid, which false their fee-estimator and for CPFP users, their feerate bump having chances to fail. It's specially concerning for LN where concurrent broadcast for the same utxo can be leveraged by a counterparty to steal channel funds. A class of attacks known as pinning achievable today [2].

Solving this means likely deploying a package relay, an old known proposition to evaluate the feerate of a whole chain of transactions to decide their mempool acceptance. Ensuring package relay effectiveness means making it part of such uniform policy laid out above, thus providing a censorship-resistant, reliable highway across the p2p network to always increase feerate of your blockspace bids. It will force a pinning attacker to enter in a feerate competition with the honest party to maintain the pin, thus cancelling the threat.

Package relay design is also pending on bumping patterns. Ideally if a LN hub is closing multiple channels at the same time, you should be able to spread one CPFP on multiple parents, which is an increase of DoS surface for the mempol. Also package relay might be the default broadcast policy by LN nodes for unilateral broadcast, as you can't dissociate if your transaction is stucking due to congestion or an ongoing pinning without global view of network mempools. In the future, if LN broadcasts account for an honest share of the whole tx-relay, it won't be free bandwidth-wise.


To conclude, upper layers of the Bitcoin stack require that single full-nodes behave in a homogeneous way such that the base network as a whole system provide a trustworthy propagation/fee bumping API [3]

I'm eager to get feedback on any subject introduced here, especially the uniform policy proposal which is really worthy of discussion and controversial for sure.

Cheers,

Antoine

[0] E.g https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017883.html or  https://github.com/bitcoin/bitcoin/issues/13283 when policy break your broadcast

[1] Again this is not a LN specific issue, timelocked vaults have the same issue

[2] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md