[bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and Package Relay

[bitcoin-dev] Advances in Bitcoin Contracting : Uniform Policy and Package Relay

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 8171 bytes --]

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

[3] In fact these requirements aren't specifics from the _new_ upper-layer
Bitcoin stack but a fundamental assumption made by anything using
timelocks/concurrent states, i.e also old-school 2013 payment channels
designs

[-- Attachment #2: Type: text/html, Size: 8655 bytes --]