V3 transactions(1) 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(2), allowing the use of ephemeral anchors(3) 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.
# 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, Alice spends the
ephemeral output in a 2 input, 1 output, taproot transaction of 152vB in size,
with sufficient feerate Ra to get the transaction mined in what Alice
considers to be a reasonable amount of time.
# 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, 1000vB in size, with a lower feerate Rm
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 162sat/vB, while
the *lowest* feerate transaction to get mined in the past 24 hours is
approximately 80sat/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. Thus the total fee of Mallory's package would have
been 6.6 * 1/2.5 = 2.6x more than Alice's total fee, and to get her transaction
mined prior to her deadline, Alice would have had to pay a 2.6x 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.
# References
1)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html,
"[bitcoin-dev] New transaction policies (nVersion=3) for contracting
protocols",
Gloria Zhao, Sep 23 2022
2)
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details,
"The replacement transaction pays an absolute fee of at least the sum paid
by the original transactions."
3)
https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
