2024.01 Vol.2

Pin the tail

The mempool is not covered by strict consensus rules like the blockchain. The Bitcoin Core node implementation supplies some policy “guidelines” though to try and make it the most efficient transaction purgatory place for miners and users. Some of the rules apply to users dealing with mempool fee weather. Maybe a user signed a transaction when fees were really low and all of a sudden the mempool is packed and fees are rising fast. They want to get their transaction in, so they bump the fee using either RBF or CPFP. All good, why do we need any rules? The original version of bitcoin shipped with some really simple rules where any transaction could be replaced in the mempool by just incrementing a counter. But this was quickly realized as a bad call and disabled. It made it very easy to DoS the network, intentional or not, since a user could just keep tweaking things and re-broadcast a transaction. All nodes would need to keep analyzing the new transactions and decide if it changes things (e.g. fee market). With no limitations it would be expensive to run a node, a centralization force (gross). But not allowing any transaction updates was very heavy-handed, so some middle grounds have been found over the years including BIP-125 which basically says “if you are willing to pay more in fees then the existing version of a transaction, I’ll take you seriously and replace you in the mempool”. This generally keeps incentives aligned for all parties.

But if you read BIP-125, it is not as straight forward as you might assume. The mempool is a complicated space. And things get more complicated when multiple parties are involved in a transaction. Transactions, following BIP-125 rules, can get “pinned” in the mempool by a user who doesn’t want the transaction to be confirmed in a block. Why would they do this? What is their incentive? Well, consider a payment channel which is a 2-of-2 multisig UTXO. Payment channels use a combo of signed transactions and timelocks to keep incentives aligned between the two parties. In a simple, uni-directional channel, there is a broadcasted funding transactions which locks up funds from Alice to Bob. To make sure Alice can get her funds back if Bob disappears, there is a signed refund transaction. But the refund transaction has a timelock which only makes it valid after three days. This is the lifetime of the channel. Alice and Bob then exchange offchain commitment transactions which update the balance between them. Before the three day refund transaction is valid, Bob broadcasts the most recent commitment transaction to lock in his funds onchain. This is when Alice performs her pinning attack. She sees Bob’s commitment transaction in the mempool which she owns a UTXO of, the funds left un-spent being returned to her, and she attaches a huge low-fee CPFP transaction to it. There is little incentive for miners to deal with this low fee package of transactions. They don’t know it is an attack, they just don’t want to do the work of picking out the transactions most valuable in the package. They might just ignore it completely! If they ignore it for longer than three days, Alice can then broadcast her original refund transaction, effectively stealing from Bob. Bob sees the pin attack happening, but following BIP-125 rules, to bump the fee on the commitment transaction he needs to pay the fee for all the child transactions as well!

Balancing the DoS attack vectors against pre-signed-transactions-not-knowing-future-fee-weather is a tricky business. Version 3 transaction relay is looking to simplify things and mitigate some of these pinning attacks.