[bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 6165 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Gloria Zhao]

[-- Attachment #1: Type: text/plain, Size: 11346 bytes --]

Hi Peter,

Thanks for spending time thinking about RBF pinning and v3.

> Enter Mallory. His goal is to grief Alice by forcing her to spend more
money
than she intended...
> ...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.

I think this is a good understanding of the goal of Rule #3, but I'm not
sure how you're getting these numbers without specifying the size and fees
of the commitment transaction. We should also quantify the severity of the
"damage" of this pin in a meaningful way; the issue of "Alice may need to
pay to replace descendant(s) she isn't aware of" is just a property of
allowing unconfirmed descendants.

Let's use some concrete numbers with your example. As you describe, we need
80-162sat/vB to get into the next block, and Alice can fund a CPFP with a
152vB CPFP. Let's say the commitment transaction has size N, and pays 0
fees.

The lower number of 80sat/vB describes what Mallory needs to shoot below in
order to "pay nothing" for the attack (i.e. otherwise it's a CPFP and gets
the tx confirmed). Mallory can maximize the cost of replacement according
to Rule #3 by keeping a low feerate while maximizing the size of the tx.

The higher number of 162sat/vB describes the reasonable upper bound of what
Alice should pay to get the transactions confirmed. As in: If Alice pays
exactly 162sat/vB * (N + 152vB) satoshis to get her tx confirmed, nothing
went wrong. She hopes to not pay more than that, but she'll keep
broadcasting higher bumps until it confirms.

The "damage" of the pin can quantified by the extra fees Alice has to pay.

For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can
increase the cost of replacement to 80,000sat.
For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing out
the descendant limit.
Rule #4 is pretty negligible here, but since you've already specified
Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a
replacement.

Let's say N is 1000vB. AFAIK commitment transactions aren't usually smaller
than this:
- Alice is happy to pay 162sat/vB * (1000 + 152vB) = 186,624sat
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 = 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(100,000vB) + 152 = 8,000,152sat
    - Mallory does succeed, Alice would need to pay ~7 million sats extra

Let's say N is 10,000vB:
- Alice is happy to pay 162sat/vB * (10,000 + 152vB) = 1,644,624
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 = 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(91,000vB) + 152 = 7,280,152sat
    - Mallory does succeed Alice would need to pay ~5 million sats extra

Let's say N is 50,000vB:
- Alice is happy to pay 162sat/vB * (50,000 + 152vB) = 8,124,624
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 = 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(51,000vB) + 152 = 4,080,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
    - The key idea here is that there isn't much room for descendants and
the cost to CPFP is very high

These numbers change if you tweak more variables - the fees paid by the
commitment tx, the feerate range, etc. But the point here is to reduce the
potential "damage" by 100x by restricting the allowed child size.

> 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.

This is exactly the idea; note that we've come from 100KvB to 1000vB.

> 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.

Note that v3 does not allow more than 1 unconfirmed parent per tx.

Let me know if I've made an arithmetic error, but hopefully the general
idea is clear.

Best,
Gloria

On Wed, Dec 20, 2023 at 5:16 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 13758 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Wed, Dec 20, 2023 at 07:13:22PM +0000, Gloria Zhao wrote:
> The "damage" of the pin can quantified by the extra fees Alice has to pay.
> 
> For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can
> increase the cost of replacement to 80,000sat.
> For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing out
> the descendant limit.
> Rule #4 is pretty negligible here, but since you've already specified
> Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a
> replacement.
> 
> Let's say N is 1000vB. AFAIK commitment transactions aren't usually smaller
> than this:

You make a good point that the commitment transaction also needs to be included
in my calculations. But you are incorrect about the size of them.

With taproot and ephemeral anchors, a typical commitment transaction would have
a single-sig input (musig), two taproot outputs, and an ephemeral anchor
output.  Such a transaction is only 162vB, much less than 1000vB.

In my experience, only a minority of commitment transactions that get mined
have HTLCs outstanding; even if there is an HTLC outstanding, that only gets us
up to 206vB.

> > 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.
> 
> Note that v3 does not allow more than 1 unconfirmed parent per tx.

Ah, pity, I had misremembered that restriction as being removed, as that is a
potentially significant improvement in scenarios where you need to do things
like deal with a bunch of force closes at once.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

Hi Peter,

Thanks for taking the time to understand the proposal and give thoughtful
feedback.

With this kind of "static" approach I think there are fundamental
limitations because
the user has to commit "up front" how large the CPFP later will have to be.
1kvB
is an arbitrary value that is two orders of magnitude less than the
possible package
size, and allows fairly flexible amounts of inputs(~14 taproot inputs
IIRC?) to effectuate a CPFP.
I'd like something much more flexible, but we're barely at whiteboard stage
for alternatives and
they probably require more fundamental work. So within these limits, we
have to pick some number,
and it'll have tradeoffs.

When I think of "pinning potential", I consider not only the parent size,
and not
only the maximum child size, but also the "honest" child size. If the honest
user does relatively poor utxo management, or the commitment transaction
is of very high value(e.g., lots of high value HTLCs), the pin is
essentially zero.
If the honest user ever only have one utxo, then the "max pin" is effective
indeed.

> Alice would have had to pay a 2.6x higher fee than
expected.

I think that's an acceptable worst case starting point, versus the status
quo which is ~500-1000x+.
Not great, not terrible.

Cheers,
Greg


On Wed, Dec 20, 2023 at 2:49 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 20, 2023 at 07:13:22PM +0000, Gloria Zhao wrote:
> > The "damage" of the pin can quantified by the extra fees Alice has to
> pay.
> >
> > For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can
> > increase the cost of replacement to 80,000sat.
> > For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing
> out
> > the descendant limit.
> > Rule #4 is pretty negligible here, but since you've already specified
> > Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a
> > replacement.
> >
> > Let's say N is 1000vB. AFAIK commitment transactions aren't usually
> smaller
> > than this:
>
> You make a good point that the commitment transaction also needs to be
> included
> in my calculations. But you are incorrect about the size of them.
>
> With taproot and ephemeral anchors, a typical commitment transaction would
> have
> a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> output.  Such a transaction is only 162vB, much less than 1000vB.
>
> In my experience, only a minority of commitment transactions that get mined
> have HTLCs outstanding; even if there is an HTLC outstanding, that only
> gets us
> up to 206vB.
>
> > > 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.
> >
> > Note that v3 does not allow more than 1 unconfirmed parent per tx.
>
> Ah, pity, I had misremembered that restriction as being removed, as that
> is a
> potentially significant improvement in scenarios where you need to do
> things
> like deal with a bunch of force closes at once.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4602 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote:
> Hi Peter,
> 
> Thanks for taking the time to understand the proposal and give thoughtful
> feedback.
> 
> With this kind of "static" approach I think there are fundamental
> limitations because
> the user has to commit "up front" how large the CPFP later will have to be.
> 1kvB
> is an arbitrary value that is two orders of magnitude less than the
> possible package
> size, and allows fairly flexible amounts of inputs(~14 taproot inputs
> IIRC?) to effectuate a CPFP.

Why would you need so many inputs to do a CPFP if they all have to be
confirmed? The purpose of doing a CPFP is to pay fees to get another
transaction mined. Unless you're in some degenerate, unusual, situation where
you've somehow ended up with just some dust left in your wallet, dust that is
barely worth its own fees to spend, one or maybe two UTXOs are going to be
sufficient for a fee payment.

I had incorrectly thought that V3 transctions allowed for a single up-to 1000vB
transaction to pay for multiple parents at once. But if you can't do that, due
to the restriction on unconfirmed inputs, I can't see any reason to have such a
large limit.

> I'd like something much more flexible, but we're barely at whiteboard stage
> for alternatives and
> they probably require more fundamental work. So within these limits, we
> have to pick some number,
> and it'll have tradeoffs.
> 
> When I think of "pinning potential", I consider not only the parent size,
> and not
> only the maximum child size, but also the "honest" child size. If the honest
> user does relatively poor utxo management, or the commitment transaction
> is of very high value(e.g., lots of high value HTLCs), the pin is
> essentially zero.
> If the honest user ever only have one utxo, then the "max pin" is effective
> indeed.

Which is the situation you would expect in the vast majority of cases.

> > Alice would have had to pay a 2.6x higher fee than
> expected.
> 
> I think that's an acceptable worst case starting point, versus the status
> quo which is ~500-1000x+.

No, the status quo is signed anchors, like Lightning already has with anchor
channels. Those anchors could still be zero-valued. But as long as there is a
signature associated with them, pinning isn't a problem as only the intended
party can spend them.

Note BTW that existing Lightning anchor channels inefficiently use two anchor
outputs when just one is sufficient:

    https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.html
    [Lightning-dev] The remote anchor of anchor channels is redundant
    Peter Todd, Dec 13th, 2023

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Gloria Zhao]

[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]

Hi Peter,

> You make a good point that the commitment transaction also needs to be
included
> in my calculations. But you are incorrect about the size of them.

> With taproot and ephemeral anchors, a typical commitment transaction
would have
> a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> output.  Such a transaction is only 162vB, much less than 1000vB.

Note that these scenarios are much less interesting for commitment
transactions with no HTLC outputs, so 162 isn't what I would use for the
minimum.

Looking at expected weights in bolt 3 (
https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-of-the-commitment-transaction)
with 1 HTLC and anchors, we get (900 + 172 * num-htlc-outputs + 224
weight)/4 = 324vB.

So, I apologize for not using a more accurate minimum, though I think this
helps illustrate the 100x reduction of v3 a lot better.
While I think the true minimum is higher, let's go ahead and use your
number N=162vB.
- Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 = 80,152sat
    - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat*
more
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(100,000vB) + 152 = 8,000,152sat
    - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = *7,949,284sat
*more (maxed out by the HTLC amount)

As framed above, what we've done here is quantify the severity of the
pinning damage in the v3 and non-v3 world by calculating the additional
fees Mallory can force Alice to pay using Rule 3. To summarize this
discussion, at the lower end of possible commitment transaction sizes,
pinning is possible but is restricted by 100x, as claimed.

Best,
Gloria

On Wed, Dec 20, 2023 at 9:11 PM Peter Todd <pete@petertodd.org> wrote:

> On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote:
> > Hi Peter,
> >
> > Thanks for taking the time to understand the proposal and give thoughtful
> > feedback.
> >
> > With this kind of "static" approach I think there are fundamental
> > limitations because
> > the user has to commit "up front" how large the CPFP later will have to
> be.
> > 1kvB
> > is an arbitrary value that is two orders of magnitude less than the
> > possible package
> > size, and allows fairly flexible amounts of inputs(~14 taproot inputs
> > IIRC?) to effectuate a CPFP.
>
> Why would you need so many inputs to do a CPFP if they all have to be
> confirmed? The purpose of doing a CPFP is to pay fees to get another
> transaction mined. Unless you're in some degenerate, unusual, situation
> where
> you've somehow ended up with just some dust left in your wallet, dust that
> is
> barely worth its own fees to spend, one or maybe two UTXOs are going to be
> sufficient for a fee payment.
>
> I had incorrectly thought that V3 transctions allowed for a single up-to
> 1000vB
> transaction to pay for multiple parents at once. But if you can't do that,
> due
> to the restriction on unconfirmed inputs, I can't see any reason to have
> such a
> large limit.
>
> > I'd like something much more flexible, but we're barely at whiteboard
> stage
> > for alternatives and
> > they probably require more fundamental work. So within these limits, we
> > have to pick some number,
> > and it'll have tradeoffs.
> >
> > When I think of "pinning potential", I consider not only the parent size,
> > and not
> > only the maximum child size, but also the "honest" child size. If the
> honest
> > user does relatively poor utxo management, or the commitment transaction
> > is of very high value(e.g., lots of high value HTLCs), the pin is
> > essentially zero.
> > If the honest user ever only have one utxo, then the "max pin" is
> effective
> > indeed.
>
> Which is the situation you would expect in the vast majority of cases.
>
> > > Alice would have had to pay a 2.6x higher fee than
> > expected.
> >
> > I think that's an acceptable worst case starting point, versus the status
> > quo which is ~500-1000x+.
>
> No, the status quo is signed anchors, like Lightning already has with
> anchor
> channels. Those anchors could still be zero-valued. But as long as there
> is a
> signature associated with them, pinning isn't a problem as only the
> intended
> party can spend them.
>
> Note BTW that existing Lightning anchor channels inefficiently use two
> anchor
> outputs when just one is sufficient:
>
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.html
>     [Lightning-dev] The remote anchor of anchor channels is redundant
>     Peter Todd, Dec 13th, 2023
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 6345 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Tue, Jan 02, 2024 at 11:12:05AM +0000, Gloria Zhao wrote:
> Hi Peter,
> 
> > You make a good point that the commitment transaction also needs to be
> included
> > in my calculations. But you are incorrect about the size of them.
> 
> > With taproot and ephemeral anchors, a typical commitment transaction
> would have
> > a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> > output.  Such a transaction is only 162vB, much less than 1000vB.
> 
> Note that these scenarios are much less interesting for commitment
> transactions with no HTLC outputs, so 162 isn't what I would use for the
> minimum.

What scenarios you consider "interesting" is not relevant. You can't pick an
arbitrary minimum based on an interesting scenario. You should pick an actual
relevant minimum.

So with that in mind, let's ask the question: Do we think it's common for
channels to be force closed without HTLCs pending? I believe the answer is
likely to be yes, because channels are only used some of the time.

Can we verify that? Well, I just checked my node, and out of the past 15 force
closes, 12 had no HTLCs outstanding. 2 had one HTLC outstanding, and 1 had 2
HTLCs.

I also checked a big node I'm connected to, fixedfloat. Again, out of the past
15 force closes, 11 had no HTLCs outstanding, with 4 having 1 HTLC
outstanding... but of those only 2 HTLCs were profitable to collect. The other
half cost more money in fees than the HTLC value.

Looks to me like the supermajority of force closes are the most boring type.
And those numbers would be even more tilted in that direction if Lightning
implementations had better economics management.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

On Tue, Jan 02, 2024 at 11:12:05AM +0000, Gloria Zhao wrote:
> Hi Peter,
> 
> > You make a good point that the commitment transaction also needs to be
> included
> > in my calculations. But you are incorrect about the size of them.
> 
> > With taproot and ephemeral anchors, a typical commitment transaction
> would have
> > a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> > output.  Such a transaction is only 162vB, much less than 1000vB.
> 
> Note that these scenarios are much less interesting for commitment
> transactions with no HTLC outputs, so 162 isn't what I would use for the
> minimum.

<snip, replied to in another email>

> So, I apologize for not using a more accurate minimum, though I think this
> helps illustrate the 100x reduction of v3 a lot better.
> While I think the true minimum is higher, let's go ahead and use your
> number N=162vB.
> - Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat
> - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
> 152 = 80,152sat
>     - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat*
> more
> - In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
> (100,000vB) + 152 = 8,000,152sat
>     - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = *7,949,284sat
> *more (maxed out by the HTLC amount)
> 
> As framed above, what we've done here is quantify the severity of the
> pinning damage in the v3 and non-v3 world by calculating the additional
> fees Mallory can force Alice to pay using Rule 3. To summarize this
> discussion, at the lower end of possible commitment transaction sizes,
> pinning is possible but is restricted by 100x, as claimed.

Also, you're writeup is still missing a very important point: existing
Lightning anchor channels solved pinning by having a CHECKSIG. Only the parties
with the right to spend the anchor channel can do that, and all other outputs
are unspendable until the commitment transaction confirms.

So the question is not whether or not V3 transactions can improve pinning
compared to a hypothetical protocol with vulnerabilities. The question, for
Lightning, is how much better or worse V3 transactions would be than the status
quo. So far, they look like the difference is marginal at best, quite possibly
worse.

Now, with other protocols, maybe we could make an argument that V3 transactions
is worthwhile and for those protocols no other solution is possible. But you
have not attempted to make that argument in the documentation provided in your
pull-req(s).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]