Gloria Zhao, Bitcoin Core developer, Brink fellow, and recent Okcoin grantee, presents some possible attacks against the Lightning network, and how her work on package relay can help mitigate them.
TL;DR
- Bitcoin has a “never compromise on security” design philosophy, because its key value proposition is the ability to operate in an adversarial environment.
- L2 contracting protocols like Lightning try to allow for more features, scalability, and privacy, but are vulnerable to some censorship attacks in transaction relay.
- Package relay is an L1 transaction relay improvement to close these attack vectors and thus strengthen Lightning’s security model.
Explore Bitcoin’s open source development
Bitcoin’s design philosophy
As Bitcoin’s most valuable properties are that it doesn’t require trust and that it can resist corruption, Bitcoin developers are typically uncompromising when it comes to security. This engineering philosophy contrasts with the “move fast and break things” model that Silicon Valley loves. Open failure cases are fine when the key value proposition is convenience – the worst case scenario is our burrito wasn’t delivered and we can dispute the credit card charge. They are not acceptable when we want all normal users’ money to resist state-level censorship and when we cannot rely on the law to punish theft.
Giving priority to stability and security doesn’t mean we’ll never have feature-rich financial products or thousands of transactions per second in Bitcoin. It just means it may take longer, because we don’t cut any corners or lean on crutches such as chain roll-backs, an off-switch, or a registry of validators’ real world identities. Projects using weaker security assumptions are not “trustless,” though they perhaps provide value elsewhere. Bitcoin’s key value proposition, however, *is* its security model.
Many developers and organizations are building a rich ecosystem of Bitcoin “layer 2” protocols (L2s). The goal of these protocols is to offer scalability, privacy, smart contracts, and more while keeping Bitcoin’s trustless model. These L2 protocols achieve this by allowing untrusted counterparties to enter into contracts embedded into Bitcoin transactions; if any party tries to cheat, the contract specifies a way for the honest party to redeem their funds within a specific time period through a “revocation” spending path.
The best example is the Lightning Network (LN), which allows users to send Bitcoin payments faster and at a higher volume. While a payment is in progress, if one party is unresponsive for some period of time, the other party can settle on-chain to get their money back. Currently, a few $100 millions of bitcoins are locked into LN channels. Huge volumes of payments have been sent successfully, with seemingly no reports of malicious activity or stolen money. This clean track record is very promising, but doesn’t justify complacency about security assumptions.
Attacks against Lightning
We’ll start with a concrete example that allows an attacker to steal the output of an unconfirmed Lightning payment (Hash Time-lock Contracts, HTLCs). Imagine an honest user, Bob, with two channels: One is open with Mallory and one with Alice. Let’s say Alice routes a payment through Bob to Mallory. If the protocol works as intended, the payment is atomic: Either Bob and Mallory both receive their payments or neither do. In this attack, Bob will pay Mallory, but Alice will not pay Bob.
At each hop, channel counterparties represent the ongoing payment using two new commitment transactions (one for each counterparty). Each commitment transaction includes an HTLC output with two relevant spending paths: The recipient using the payment preimage or the sender after a timelock. Alice can refund herself if Bob doesn’t claim the money by a given time (t6). Once Bob’s payment to Mallory goes through, he should immediately redeem his payment from Alice.
These two commitment transactions both spend the same unspent transaction output (UTXO) from their channel funding transaction. They are “double spends” of each other and thus cannot both be mined in a block or accepted into a memory pool (mempool) – a node’s individual database of unconfirmed transactions. They also pay the same feerate that cannot be changed later on (it would require both parties to sign a new transaction), which means they cannot replace each other via regular Replace by Fee rules (RBF). This means that, if Mallory broadcasts her commitment transaction, any mempool that accepts it will reject Bob’s commitment transaction later.
Let’s say there is a somewhat high volume of transactions being broadcast currently, and the feerate of Bob and Mallory’s commitment transactions is lower than that of 40MWu (10 blocks worth of transactions) of the transactions in miners’ mempools. Mallory broadcasts her commitment transaction and Bob doesn’t notice, since it hasn’t been mined.
At time t5, Bob sees that Mallory isn’t responding, so he broadcasts his commitment transaction to redeem his refund. It doesn’t confirm. He can’t ask Mallory to sign a new transaction with a higher feerate, since she’s not responding (and trying to steal money from him). Understanding that miners prioritize transactions based on ancestor feerate, he attaches a high-fee child to his commitment transaction to bump its priority using Child Pays for Parent (CPFP). But it still doesn’t confirm! In fact, mempools that already have Mallory’s commitment transaction reject his transactions, despite the very attractive fees offered by his fee-bump.
At time t6, Alice and Bob resolve their payment by refunding Alice. Through a similar race to broadcast, Mallory redeems her payment from the HTLC output using the preimage, but this preimage is useless to Bob now that Alice has already been refunded. Bob has lost the HTLC amount.
This attack is not possible if the commitment transactions’ feerates are high enough to be mined immediately: Mallory cannot get a “head start” by broadcasting ahead of time. However, fee estimation is never certain and overestimation results in wasted money. An attacker can also create high traffic by launching this attack on thousands of LN channels at once – it’s simply impossible to fit so many commitment transactions into one block. The mempool policy known as Replace by Fee (or RBF) has limitations that may give an advantage to those who broadcast early or can pay miners out-of-band to prioritize their transactions.
Eltoo, a proposed enforcement layer for LN (and potentially other types of smart contracts), would greatly simplify its protocol and security requirements, but relies heavily on the assumption that fee-bumping works on individually-low-feerate transactions. For example, incorporating fees into each Update Transaction would require subtracting some value from the inputs, causing the channel to “leak” money at each state update. A simple solution exists: Channel parties construct and sign Update Transactions without any fees, and add fees by attaching high-fee descendants (CPFP) at broadcast time. However, the vast majority of nodes today will reject a 0-fee transaction regardless of how much its child transaction is paying.
Source: Richard Myers, 2011
We might generalize these attacks for all Bitcoin “smart contract” and L2 protocols that rely on time-sensitive, presigned transactions to mitigate cheating. An honest party trying to settle on-chain must meet a certain confirmation target to be effective, but a presigned transaction’s feerate cannot be adjusted at broadcast time. This combination of conditions makes fee-bumping imperative for security. Currently, there is no reliable way to fee-bump presigned transactions.
What’s package relay?
We aim to create fair, fee-based market for block space so the *only* security assumption we rely upon is “miners are economically rational and want to maximize fees.” Incentive-compatible policies that exist today help users bump the priority of their transactions by attaching high-fee descendants (CPFP) or creating replacement transactions (RBF).
However, as illustrated through the attacks above, only considering transactions one at a time for submission to the mempool creates a limitation in the node’s ability to determine which transactions have the highest fee rates, since it cannot take into account descendants until all the transactions are in the mempool. Similarly, it cannot use a transaction’s descendants when considering which of two conflicting transactions to keep.
Package relay is a proposal to fix these issues byupgrading our mempool logic and transaction broadcast mechanisms to consider packages of transactions as a unit instead of separately. Network-wide adoption of these policies would create a more purely-feerate-based market for block space and allow contracting protocols to adjust fees (and therefore mining priority) at broadcast time.
However, attempting to design secure transaction validation logic comes with its own challenges. Unconfirmed transactions are cheap to create (no Proof of Work required) and, if we’re not careful, resource-intensive to validate. Malicious nodes on the permissionless peer-to-peer network may send us data causing us to stall, burn through CPU, run out of memory, crash, ignore data from honest peers, or reveal identifying information about our node. We also cannot use a reputation system to avoid malicious nodes and need to keep resource requirements minimal (i.e. a rapsberry pi node should be able to participate in package relay). Again, this combination of requirements is challenging but non-negotiable, since Bitcoin aims to be a censorship-resistant network.
To learn more about how Bitcoin development works and how it’s funded, read our free report, Giving Back to Bitcoin.
