The last few years have seen few new protocols spawning up in the Bitcoin ecosystem. The goal range is quite wide : payment systems (Lightning Network, statechain), asset management (vaults) financial instrument (DLC), privacy-enhancement tool (Coinswap). Those time-sensitive contract protocols are designed around the same model.
They involve a fixed set of participants, which negotiate state changes locally, only relying on the blockchain in case of disagreement. These state changes are encoded in pre-signed transactions. Timelocks are used to encumber them and thus order concurrent state transitions. Their security lean on the ability of one of the participant to timely confirm a transaction and thus enforce onchain its offchain balance.
Those protocols are coming with new security and robustness challenges. One of the most concerning class of vulnerability affecting L2 protocols is the tx-relay jamming one. A malicious participant exploits an interaction with the base layer tx-relay and mempools rules to break protocol security.
Among known tx-relay jamming, we can sort the following vulnerability:
- standardness malleability
- witness malleability
- tx-pinning
- mempools-partition
This document is WIP and very welcome any suggestion improvement.
In some L2 protocols, transactions are cooperatively built by participants. They contribute to the number of outputs, inputs, feerate, timelocks, etc. Any of these elements can be leveraged by a participant to make the transaction non-standard and thus unrelayable by the Bitcoin Core nodes. One example is CVE-2020-26895, which was affecting LND software.
Mitigating may happen at the protocol design level by incorporating directly references to a node relay policy. Protocol implementations may also relies on new tooling to verify standardness of their transactions against their node policies. Tx-relay policies uniformization would be harmful as it would require a consensus on tx-relay rules. Note, there is no such thing as tx-relay/mempools "rules" as they're implmentation/version/operator-defined.
A "testmempoolaccept" for package or libstandardness would be a solution. It should be noted that lightweight client may not have access to the UTXO set and transaction might have a minimal feerate, under the mempool effective one. Also, producing local signature isn't great w.r.t to hardware wallet policy.
A transaction witness might be inflated by a malicious participant to decrease the overall transaction feerate thus making the transaction stuck in the mempool. E.g, within a witnessScript with alternatives branches, the most-expensive one can be used instead of the cheapest one when satisfying solutions for both are known. This event may trigger a fund loss if the lack of transaction confirmation can be exploited by a participant (e.g onchain DLC) or an easy-to-trigger time-value DoS (e.g dual-funded channel, zero-conf channel, ...).
New scripts enhancements like Taproot/Tapscript and multi-party protocols built around are likely to make this issue more sensible.
Beyond allowing cheaper-witness replacement, it's
likely that change to the RBF handling (incrementalrelayfee) should be envisionned, at this check
currently force an absolute fee increase to replace a witness.
Miniscript non-malleable signing assumptions doesn't seem to overlay with L2 protocol ones, which means it's likely you won't be able to use the current Miniscript toolchain to mitigate this issue. L2 protocol designers should be aware of these issues and be more strict on the witnessScript admitted in cooperative transaction building.
Transaction pinning consists in a malicious protocol participant abusing of Bitcoin Core mempools DoS protection to pin one of its transaction and thus breaking time-sensitive transaction confirmation.
Post-anchor Lightning is still subject to two flavors of pinnings on the commitment-tx level, described as scenario 2a) and 2b) here. More details are explained in this LN-specific summarizing thread
CoinSwap first version of the protocol had a pinning issue due to a preimage transaction which was spendable without any timelock restriction thus enabling a malicious counterparty to block until refund tx was valid.
Onchain DLC has a current pinning issue where a malicious counterparty would pin its funding input to prevent confirmation of the funding transaction. In case of unfavorable outcome for the malicious counterparty, it would be able to spend its funding input thus cancelling the DLC. The honest party would be devoided of its outcome gain.
Note, pinning attacks are particularly concerning for LN where any previous commitment state can be used as a malicious pinning. Knowledge of network mempools being limited, a honest node will never learn which state is faultive and won't be able to build a propagating CPFP.
Few mitigations have been discussed.
A first alternative would be to prevent transaction pinning, low-fee children attached to a RBF-transaction shouldn't be relayed, where low-fee is defined with block confirmation relevance.
A second alternative is package RBF, where a higher-fee package replaces a lower-fee one. It also likely implies getting ride of absolute fee logic in the mempool to evaluate package or transaction acceptance only on feerate.
Three different designs can be envisionned for package relay:
- receiver-initiated
- relay-initiated : at inv/tx sending, the relay nodes ties a low-feerate parent to a high-feerate child based on its local mempool
- sender-initiated : original broadcast sender marks a chain of transactions and is evaluated as a whole
Further, any package-relay design proposal should be evaluated w.r.t to privacy, bandwidth and interoperability with upcoming P2P extension (e.g Erlay).
Alternatively, few softforks have been proposed to solve pinning :
- Transaction Fee Sponsorship
- SIGHASH_NOINPUT and further malleability sighash would enable to attach a bumping input directly on a better-feerate proposal
A more theoretical scenario assumes a powerful attacker which would even bypass the security enhancement provided by package relay. Assuming ability to partition network mempools, network topology knowledge and inter-layer mapping, an attacker. is able to obstrucate propagation of victim's high-feerate package by pinning a higher-fee, conflicting packages between victim's node and miner mempools.
On the onchain-side, outbound tx-relay peers rotation to sweep and reach ~80% of the network in less than the targeted timelocks would be an improvement. It would make the tx-relay less static, thus less prone to global manipulation.
On the offchain-side, wide-deployment of watchtowers, by duplicating the full-node infrastructure would make it far harder to isolate a node from the rest of the network and thus launch this kind of attacks.
Vulnerabilities previously described are ranking from easy-to-execute to really hard even with specialized knowledge. While mitigating them, a preliminary work of carefully assessing them should be a way to inform mitigation design and also sort which ones to address first.
Grounding security discussions with practical experiments would avoid byzantine, endless debates among the Bitcoin protocol dev community. Each vulnerability can be assess from a simple unit test to mainnet demonstration.
Teaching back new generation of L2 devs to design carefully their protocols with those tx-relay jamming in mind would be a huge step forward. If L2 pioneers have discovered those cases by hitting them the knowledge transmission isn't guarantee to work efficiently.
Designing secure fee-bumping and tx-rebroadcasting module is still a WIP. Those modules are part of any L2 protocol stack and should be considered with the same care than cryptographic libraries, any bug or wrongdoing is likely to open the way for fund loss.
It sounds base layer devs should be really careful when upgrading tx-relay code to not tighten transaction acceptance and mistakenly break L2 protocols by making their transactions unrelayable.
Even if this document analyzes safety of L2 protocols under the tx-relay jamming viewpoint, a lot of considerations laid out holds to make those protocols robust against mempool-congestion. A LN user safety not only depends on mitigations against counterparty misbehavior but also on protocol and implementations being mempool-congestion fault-tolerant. Advanced systematic risks scenarios should be investigated like loitering scenarios due to high levels of mempool congestion.
Anyway, the Bitcoin protocol stack is still early and now is a great time to start addressing tx-relay jamming and mempool-congestion fault-tolerance at the base layer.