V3 Transactions¹ is a set of transaction relay policies intended to aim L2/contracting protocols, namely Lightning. The main aim of V3 transactions is to solve Rule 3 transaction pinning², allowing the use of ephemeral anchors³ that do not contain a signature check; anchor outputs that do contain a signature check are not vulnerable to pinning attacks, as only the intended party is able to spend them while unconfirmed.

The main way that V3 transactions aims to mitigate transaction pinning is with the following rule:

A V3 transaction that has an unconfirmed V3 ancestor cannot be larger than
1000 virtual bytes.

Unfortunately, this rule — and thus V3 transactions — is insufficient to substantially mitigate transaction pinning attacks because \(1000\mathrm{vB}\) is still much larger than a typical commitment transaction and ephemeral anchor spend.

This was originally published to the Bitcoin Development mailing list, and is published here with corrections suggested by Gloria Zhao.

The Scenario

To understand why, let’s consider the following scenario: Alice has a Lightning channel with Bob, who has become unresponsive. Alice is using a Lightning protocol where using V3 commitment transactions with a single OP_TRUE ephemeral anchor of zero value. The commitment transaction must be broadcast in a package, containing both the commitment transaction, and a transaction spending the anchor output; regardless of the fee of the commitment transaction, this is a hard requirement, as the zero-valued output is considered non-standard by V3 rules unless spent in the same package.

To pay for the transaction fee of the commitment transaction, \(163\mathrm{vB}\) in size⁴, Alice spends the ephemeral output in transaction, \(152\mathrm{vB}\) in size⁵, with sufficient feerate \(R_a\) to get the transaction mined in what Alice considers to be a reasonable amount of time. In total, Alice must pay sufficient fees to get \(152\mathrm{vB} + 163\mathrm{vB} = 315\mathrm{vB}\) mined.

The Attack

Enter Mallory. His goal is to grief Alice by forcing her to spend more money than she intended, at minimum cost. He also maintains well connected nodes, giving him the opportunity to both learn about new transactions, and quickly broadcast transactions to a large number of nodes at once.

When Mallory learns about Alice’s commitment+anchor spend package, he signs a replacement anchor spend transaction, \(1000\mathrm{vB}\) in size, with a lower feerate \(R_m\) such that the total fee of Alice’s anchor spend is <= Mallory’s anchor spend (in fact, the total fee can be even less due to BIP-125 RBF Rule #4, but for sake of a simple argument we’ll ignore this). Next, Mallory broadcast’s that package widely, using his well-connected nodes.

Due to Rule #3, Alice’s higher feerate transaction package does not replace Mallory’s lower fee rate, higher absolute fee, transaction package. Alice’s options are now:

1. Wait for Mallory’s low feerate transaction to be mined (mempool expiration does not help here, as Mallory can rebroadcast it indefinitely).
2. Hope her transaction got to a miner, and wait for it to get mined.
3. Replace it with an even higher fee transaction, spending at least as much money as Mallory allocated.

In option #1 and #3, Mallory paid no transaction fees to do the attack.

Unfortunately for Alice, feerates are often quite stable. For example, as I write this, the feerate required to get into the next block is \(162\frac{\mathrm{sat}}{\mathrm{vB}}\), while the lowest feerate transaction to get mined in the past 24 hours is approximately \(80\frac{\mathrm{sat}}{\mathrm{vB}}\), a difference of just 2x.

Suppose that in this circumstance Alice needs to get her commitment transaction mined within 24 hours. If Mallory used a feerate of 1/2.5th that of Alice, Mallory’s transaction would not have gotten mined in the 24 hour period, with a reasonable safety margin. The ratio of total fee of Mallory’s package compared to Alice’s would have been:

Thus to get her transaction mined prior to her deadline, Alice would have had to pay at least a 1.48x higher fee than expected.

Multi-Party Attack

Mallory can improve the efficiency of his griefing attack by attacking multiple targets at once. Assuming Mallory uses 1 taproot input and 1 taproot output for his own funds, he can spend 21 ephemeral anchors in a single 1000vB transaction.

Provided that the RBF Rule #4 feerate delta is negligible relative to current feerates, Mallory can build up the attack against multiple targets by broadcasting replacements with slightly higher feerates as needed to add and remove Alice’s.

The cost of the attack to Mallory is estimating fees incorrectly, and using a sufficiently high feerate that his transaction does in fact get mined. In that circumstance, if he’s attacking multiple targets, it is likely that all his transactions would get mined at once. Thus having only a single attack transaction reduces that worst case cost. Since Mallory can adding and remove Alice’s, he can still force multiple Alice’s to spend funds bumping their transactions.

Solutions

Replace-by-Feerate

Obviously, this attack does not work if Rule #3 is removed for small transactions, allowing Alice’s transaction to replace Mallory via replace-by-feerate. In the common situation where mempools are deep, this is arguably miner incentive compatible as other transactions at essentially the same feerate will simply replace the “space” taken up by the griefing transaction.

Restrict V3 Children Even Further

If V3 children are restricted to, say, 200vB, the attack is much less effective as the ratio of Alice vs Mallory size is so small. Of course, this has the disadvantage of making it more difficult in some cases to find sufficient UTXO’s to pay for fees, and increasing the number of UTXO’s needed to fee bump large numbers of transactions.

Footnotes