Transactions propagation design goals #19820

During the last P2P meeting, @sdaftuar pointed the lack of a transactions propagation framework thus hindering progress in the tx-relay network area, devoid of clear goals to achieve.

This is a blocking issue in a spawn of subjects, like countering cheap RBF replacements, increasing mempool feerate of resources constraints nodes, better support of Bitcoin applications with more demanding fee/tx-relay requirements, scope of tx-rejection filter, etc

Core mechanisms of Tx-Relay

I think one of the starter goal of the tx-relay network is obviously to let miners discover the best-feerate transactions candidate for inclusion in block. As Bitcoin censorship-resistance lays on distribution of mining, bias in tx-relay topology privileging a subset of miners with an advantage in fee discovery may provoke disequilibrium beyond their hashrate contributions. Thus an unstructured p2p network, vetted of uniform tx-relay peers selection is likely the best option. A distributed network is also more-robust against infrastructure disruption or targeted transaction censorship.

An additional goal is preserving the pseudonymity of transactions original broadcaster which can be enforced with high guarantees only if tx-relay topology is non-observable by a protocol participants or a coalition of them. Introduction of randomized timers at propagation (e.g #14897) is an improvement towards this direction, even if research has hinted that the number of tx-relay mechanisms potentially exploitable to learn about topology is likely wide. Future improvements like mempool rebroadcasts (https://github.com/bitcoin/bitcoin/pull/16698) or initial-broadcast-over-Tor-only may improve the situation.

Lastly, an other important goal to consider is bandwidth-savings, as underscored in the Erlay paper, a too prohibitive tx-relay cost disincentives potential node operators, especially running full-relay public ones contributing the most to good health of the network. This goal might be in trade-offs with aforementioned ones, where tx-relay peering redundancy increases robustness and higher mempool rebroadcast frequencies add noise to the propagation graph at the price of higher bandwidth costs.

Tx-Relay & Node Policies

If the set of messages as inherited from first protocol versions or specified in peer services BIPs defines what bitcoin data structures are accepted by compliant peers, AFAIU it doesn't mandate a relay behavior, neither outlaw a superset of constraints on p2p messages, at the discretion of local node. This superset of constraints is I guess what people commonly called P2P network transaction policy, even in fact such policies vary by full-node implementation, versions and local node settings.

On the Core side, such policies encompass some DoS/vulnerabilities counter-measures like SCRIPT_VERIFY_MINIMALIF at the script interpreter level or MIN_STANDARD_TX_NONWITNESS_SIZE at the mempool level, invariants which can't be disabled by local settings, so we can qualify them as implementation/version policy . Another range of policies checks are vetted with hopefully anti-DoS default values like incrementalRelayFee or m_limit_descendant but configurable by node operator to express a different pricing of resources offered to the network or increasing the chance to learn good feerate chain of transactions by accepting higher DoS risks.

Due to this divergence of policies across the network and adding to the absence of events order in a distributed system, mempools convergence has never been considered as a goal. However, there is a p2p mechanism for peers to discover and adapt its peers policies, namely feefilter. This mechanism prevent bandwidth-waste by will-be-rejected low-feerate transactions. Further p2p mechanisms could be devised to improve peer policy negotiation, like txfilter announcing the local standardness applied or utxofeerate announcing the feerate of a package for a known utxo spend candidate. That said, communicating more information to opportunistically save more bandwidth is likely quickly bounded.

Fee/Relay Assumptions for Bitcoin Applications

Bitcoin applications aiming to confirm their transactions should ensure first to be connected to a high number of tx-relay peers, then ensure these transactions are formatted to pass at least testmempoolaccept of their local nodes. If a propagation failure is detected or suspected, a) a rotation should be triggered to probabilistically find a peer with an identical policy, at least for the subset of policy rules you share or b) a warning can be triggered back to the user hinting to do something about likely a badly-formatted transaction.

Such model doesn't work great with regards to multi-party Bitcoin applications (e.g LN or vaults), where signing interactivity is costly or impossible. Further, if a transaction is time-sensitive with regards to advancing state of protocol forward, propagation failures are direct risks for fund safety. Even further such potential propagation failures could be exploited by a malicious counterparty, if applications participants are assumed to be distrusted. Such application can never be sure that transaction will confirm but should be able to express its best-feerate bid for this time-sensitive transaction, even if bid isn't won due to a better blockspace demand.

Any such application/protocol developper will be confronted with the following questions:

• how to decide the format of my transactions (size, scripts, witness, minimal fee, ...) ?
• what should be the size/weight of chain of transactions ?
• what should be my tx-relay strategy and should rebroadcast/peer rotation be triggered ?
• what fee-bumping strategy are offered between RBF, CPFP, Parent-Pay-For-Child, etc ? how network mempools will evaluate each one ? how a malicious counterparty could leverage them ?
• what dev process will follow ecosystem/implementations in case of rules tightening/changes potentially hindering application/protocol security, e.g what are Core guarantees wrt to carve-out backward-compatibility ?

Historically, we have an example of BIP 125, specifying out the mempool RBF policy, ready to be consumed as an interface by Bitcoin applications. But otherwise, due to fear of silently breaking an obscure policy rule, some application are literally leaking them in their stack (see https://github.com/ElementsProject/lightning/blob/4302afd9a58f0c455bb812b63e9cdf377ebb74d4/bitcoin/signature.c#L214)

Of course to avoid getting stuck in endless debates, here few questions we may evaluate as a guideline:

• what have been historically propagation assumptions of Bitcoin applications ? how newer class of Bitcoin applications should conceive their operational and security models with regards to propagation ?
• should we support requirements of newer classes of Bitcoin applications ? If so, what should be the scope and expressivity of an fee/tx-relay API rules ?
• what set of constraints (DoS, bandwidth, privacy, deployment, ...) do we have to bind to ?

See CVE 2020-26895 as the original motivation for starting this issue : https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html

In the context of second-layer protocols, can a malicious counterparty abuse our tx-relay DoS protections to directly prevent honest time-sensitive transactions to propagate ? Sadly yes.

Excellent research! Thanks a lot @ariard for making us stronger! ❤️

And thanks for taking the time to request a CVE assignment too: that allows for easy unambiguous referencing.

This is clearly important and the work on the CVE is really impressive. On this issue though perhaps you can tentatively start answering the questions you pose @ariard to move this forward. It will be your personal opinion obviously but that's fine, it is easier to have discussion if someone attempts to answer the questions rather than just leave them open ended.

edit: Perhaps you can add a link to the P2P meeting log where this was initially discussed, presumably http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-08-25-15.00.log.html

@michaelfolkson

First, have a look on this gist : https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af, it's a sum-up around tx-relay jamming and its implications on L2/contract protocols. Note that the set of vulnerabilities (money loss, timevalue DoS, "contract cancelling", ...) is different in function of each protocol (CoinSwap, Lightning, DLC, ...). Maybe we can translate the gist as a dev wiki page ?

W.r.t to questions, answering them is function of the L2 protocol considered (CoinSwap, Lightning, DLC, ...). What I can do is write down a tx-jamming analysis for the main ones.

About standardness malleability, see logs : https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#topic-reducing-cve-2020-26895-class-of-bugs-and-tx-standardness-ariard, where the majority opinion (which I adhere too now) is that there is no such thing as "bitcoin's tx relay rules". So in the future, the burden would be more on L2 protocol designer to make the less assumptions possible on their transaction formats.

Anyway, tx-relay jamming/mempool congestion fault-tolerance for L2 protocols is a wide subject, I'm glad to get help.

Thanks for this @ariard. There is really useful information buried in some of these docs but some of these are really long and there is a lot of high level fluff imo that doesn't drive the discussion forward. I'm scanning through these trying to find where the useful information is.

In terms of the problem being different for each protocol, DLCs and CoinSwap are very early in their development. Stalling because we don't what their final form will be doesn't make much sense to me. Of course the teams working on them should be consulted once there is a concrete proposal in case the solution doesn't work for them. But directly focusing on solving Lightning specific problems (which we are more clear on) make sense to me if any progress is going to be made.

I don't mean to sound harsh but we need to move from high level philosophy to a focus on which solutions are optimal for specific Lightning problems and doable from a Core context imo. If the burden is on L2 protocols (e.g. standardness malleability) rather than Core then there is nothing to discuss on this Core issue and it should be closed. But there does seem to be some things that are potentially solved from a Core perspective. I'm just trying to figure out exactly what those things are and will keep reading.

I want to be sure we understand well the vulnerabilities vectors before to rush on integrating some complex change in Core to realize after the fact it doesn't work completely (e.g carve-out and the one-block CSV lift in anchor outputs). IMHO, those issues aren't well understood both by L2/Core devs, so it's still too early to decide if it should be entirely the burden of one side or the other. And the most likely outcome is Core will need to introduce mechanisms (e.g "libtxstandardness", package relay, cheaper witness acceptance) which are well-used by L2 devs while minimizing attack surface at L2 protocol design.

I still have to do the assessment on pinning. Meanwhile, if you have any suggestion to make the gist better and ease understanding of each vector, feel free to comment there :)

Closing this issue, I'll dry-up all the substance in new repository, L2-zoology Aiming to document and discuss in details all the open problems raised in this issue :)