policy: nVersion=3 and Package RBF #25038

I mean a situation like this:

{A, B, C} are in the mempool, and A is already at the descendant limit (101KvB). {X, Y, Z} is a package where X conflicts with B and will replace {B, C}. However, when we run descendant limit checks, it will look like A’s descendants include {B, C, X, Z} and reject it. But actually A’s descendants will only include {X, Z} after the replacement.

I think it could be a limitation for second-layer package issuers, where a child-with-parents package aims to replace more than 5 LN commitment transactions at the same time. A counterparty could extend the 5 non-related commitment transactions descendants until reaching max in-mempool limits, thus interfering with their potential package-RBF.

Am I correct ? That said, I remember we’ve already said that child-with-parents to replace multiple LN commitment transactions open the door to malicious interferences.

I believe this issue can unfortunately arise even when you’re replacing a single LN commitment transaction. Imagine that you’re trying to replace {commitTxAlice, anchorTxAlice} but Alice has created anchorTxAlice to have 100 outputs and broadcast one child tx per output, you’re already hitting the 100 transactions limit…

I believe that the only thing that can save Bob here is to broadcast {commitTxAlice, anchorTxBob} by relying on the CPFP carve-out rule to get Alice’s commitment to confirm. But in order to do that, Bob needs to somehow get the signed commitTxAlice (which never appeared in his mempool since his mempool contains commitTxBob).

So this rule is an issue for L2 protocols, but it is also a protection against high mempool churn, so it’s hard to draw the line.

I think it could be a limitation for second-layer package issuers, where a child-with-parents package aims to replace more than 5 LN commitment transactions at the same time. A counterparty could extend the 5 non-related commitment transactions descendants until reaching max in-mempool limits, thus interfering with their potential package-RBF.

Yeah, batching multiple commitment transaction replacements isn’t very safe. That’s why we have the “Warning: Batched fee-bumping may be unsafe for some use cases. Users and application developers should take caution if utilizing multi-parent packages.” in the doc.

I believe this issue can unfortunately arise even when you’re replacing a single LN commitment transaction.

I don’t think this scenario is possible with our current mempool policy. With our descendant limit at 25, anchorTxAlice wouldn’t be able to have 100 children.

This rule startled me a bit at first, it may be worth mentioning that if you want to update the package’s child, you should do a normal RBF of just that child.

What you mean is that package-rbf applies for the case where we want for example to replace {commitTxAlice, anchorAlice} by {commitTxBob, anchorBob} where commitTxAlice and commitTxBob conflict, but we cannot use package-rbf to replace {commitTxAlice, anchorAlice1} by {commitTxAlice, anchorAlice2} where anchorAlice2 pays more fees than anchorAlice1. In that case we should submit anchorAlice2 alone and it will go through the usual RBF rules. Is that correct?

Also you don’t want to mix up package-rbf and normal rbf, so a child tx cannot create conflicts “outside of the package” IIUC.

My head hurts :laughing:

I’m not 100% sure I’m understanding this rule correctly, can you let me know if the following example makes sense?

Let’s imagine we have {commitTxAlice, anchorTxAlice} in the mempool that we want to replace. What we really want to do is to replace commitTxAlice by commitTxBob (the child is just a tool to achieve that). We ask bitcoind to fundrawtransaction to ensure our anchorTxBob adds enough funds. bitcoind adds an unconfirmed (but safe) wallet input:

0+-------------+
1| commitTxBob |---------+
2+-------------+         |      +-------------+
3                        |      |             |
4+------------------+    +----->| anchorTxBob |
5| previousWalletTx |---------->|             |
6+------------------+           +-------------+

If we include previousWalletTx in the package, this package-rbf would work, right? But if we don’t include previousWalletTx in the package, this would be rejected?

But what if previousWalletTx itself has an unconfirmed parent? We cannot include this grand-parent in the package (since packages are only parents-with-single-child).

This isn’t directly bringing an unconfirmed input, but it is indirectly bringing one. Is that ok? If that’s ok, why wouldn’t it be ok to just allow adding new unconfirmed inputs in the first place?

(Sorry for my earlier comment, I was confused)

If we include previousWalletTx in the package, this package-rbf would work, right?

Yes. It’s fine because it’s one of the direct parents of anchorTxBob.

But if we don’t include previousWalletTx in the package, this would be rejected?

If you mean anchorTxBob now only has 1 unconfirmed input, commitTxBob, actually this would be accepted.

If you mean that previousWalletTx was submitted ahead of time, that should still be okay because the code will remember to exempt previousWalletTx from the “no new unconfirmed” rule.

But what if previousWalletTx itself has an unconfirmed parent?

Based on this rule, if previousWalletTx has another unconfirmed parent, this would be rejected.

Since we are introducing a new form of RBF that doesn’t currently exist, now might be the best time to at least improve the BIP 125 rules to be incentive compatible in all situations (though this comes at the cost of making replacements potentially more expensive).

In particular what I have in mind is that we require the ancestor feerate of the child transaction to be higher than the actual feerate of all transactions that would be evicted. This is conservative but I think would ensure that we don’t have any situations where there are transactions being replaced that might appear in the next block, while the new transactions do not.

Would this be too conservative for the use cases that we have in mind?

Sure – consider the case where you have a transaction A(100vb, 1sat/vb) and child B (100vb, 10sat/vb) in the mempool. Total fees = 1100 sat.

A package comes in with parent A’(100vb, 1sat/vb) and child B’(1000vb, 2.5sat/vb). Total package fees = 2600 sat.

Under the rules described here, package (A’, B’) could replace (A, B) in the mempool, because total fees are paid for and there’s enough left over fee to pay the incremental relay fee of the new package (1500 sat/1100 vb). Also the package feerate is higher than that of the direct conflicts[1].

The deficiency in the logic is that we’re not looking at the feerates of the transactions that would be evicted – even though their absolute fee is being paid, their feerate could be even higher than the transactions that would replace them. Calculating the effective feerate that such a transaction would have in our mining code is tricky (because a sibling could pay for an ancestor, it’s not quite right to just consider ancestor feerate), but using its feerate is a conservative check here – any descendant that is paying for its confirmation would be caught in this logic, and its (higher) feerate considered if necessary.

For evaluating the mining suitability of the new transactions coming in, I think we can just look at the ancestor feerate of the package, which is a lower bound on the attractiveness of the new transactions. (I think this would also allow us to relax the rule against new unconfirmed inputs.)

[1] In looking at this example, I noticed that BIP 125 as drafted seems to misstate an important check we perform in our current RBF policy, namely that we compare the feerate of a new transaction coming in to the feerate of the existing transactions that it directly conflicts with. (Without this check, a small high fee transaction could be replaced by a large low fee transaction!). From my first glance at the code in this PR, it looks like the code itself does a similar check for packages (comparing the package feerate to the feerate of the direct conflicts) so that is good at least, but the description of the logic in the documentation should point out that there is some feerate check happening as well.

require the ancestor feerate of the child transaction to be higher than the actual feerate of all transactions that would be evicted. This is conservative but I think would ensure that we don’t have any situations where there are transactions being replaced that might appear in the next block, while the new transactions do not.

I think this is a sensible addition. I cannot think of any easy attacks since it’s only the directly conflicting transactions and not their descendants (i.e. I don’t have the concerns stated in #23121 (comment)).

Btw, don’t we want min(package feerate, child ancestor feerate)?

In pseudocode for a child-with-unconfirmed-parents package:

0for each tx in directly_conflicting_transactions:
1    if min(package_feerate, child.ancestor_feerate) <= tx.individual_feerate
2        fail

With this, do you think it would be acceptable to remove the “no new unconfirmed inputs” rule in package RBF?

we compare the feerate of a new transaction coming in to the feerate of the existing transactions that it directly conflicts with

Right, this wasn’t in BIP 125. I also misinterpreted that part of the code to be part of the other fee-related rules and just a “fail fast” piece of logic, and didn’t include it in # #23711 either (gah!). Just opened #25382 to add test coverage for it in isolation + add it to doc/policy/replacements.md

it’s only the directly conflicting transactions and not their descendants

Could you clarify that? I’m not sure whether @sdaftuar’s example contradicts this claim or not.

Let’s consider a mempool containing transaction A (1000vb, 1sat/vb), child B (1000vb, 10sat/vb) and grand-child C (100vb, 100sat/vb).

If we want to replace this with a package containing transaction A’ (1000vb, 1sat/vb) and child B’ (1000vb, 20sat/vb), would that work? Or would we be forced to match the 100 sat/vb of grand-child C (since @sdaftuar says the ancestor feerate of that package must be higher than the actual feerate of all transactions that would be evicted)? If so, that would be an issue, an attacker could always put a low-fee high-feerate descendant to make it very expensive to replace the first transaction in the chain, can’t they?

require the ancestor feerate of the child transaction to be higher than the actual feerate of all transactions that would be evicted. This is conservative but I think would ensure that we don’t have any situations where there are transactions being replaced that might appear in the next block, while the new transactions do not.

I think this is a sensible addition. I cannot think of any easy attacks since it’s only the directly conflicting transactions and not their descendants (i.e. I don’t have the concerns stated in #23121 (comment)).

Ah, in writing this I overlooked what you had written up in that comment and forgot about that concern. When I commented before I did indeed mean to suggest that we’d compare our estimated mining score of the new child transaction (min(package feerate, ancestor feerate) as you say) with the actual feerate of all the transactions that would be evicted, and not just the direct conflicts – if we only compare to the feerate of direct conflicts, then I believe it is still possible for a transaction that would be included in the next block to be replaced by a transaction that will confirm much later.

However now you have reminded me of the other concern, which is that a high actual feerate (but low ancestor feerate) transaction could be used to pin a package and make it difficult to evict. I’m not sure what to do about this!

Perhaps a simple, good enough approach might be to require that the child transaction’s score is better than the ancestor feerate of all the transactions that would be evicted, and the actual feerates of the direct conflicts? I just think we should do something to ensure that a new transaction package isn’t strictly worse than something that would be evicted. We’d still be missing the case where something being evicted has a lower ancestor score than its actual mining score because of an unrelated transaction that is paying for a low feerate parent, but maybe that is an edge case that we can overlook (especially since the total fees in the mempool are still going up and the first order approximation of mining desirability is also going up).

I was trying to think about whether this approach might be attackable in some way to either muck with fee estimation or attack someone’s mempool with low quality transactions, but I need to give it more thought.

An alternate approach to this problem might be to define some new (opt in) relay policy that limits the scope of descendant transactions in some way, and then only implement a package RBF policy that would interact with transactions that meet that limited criteria. That might be a good direction to go if our broader attempts at this problem result in behavior that’s not incentive compatible..?

Perhaps a simple, good enough approach might be to require that the child transaction’s score is better than the ancestor feerate of all the transactions that would be evicted, and the actual feerates of the direct conflicts?

To my understanding of this dual-criteria approach (better ancestor score than the set of evicted transactions and better feerate of the direct conflicts) I’m not sure it’s robust against pinning attackers.

Let’s say you have a mempool containing parent A (1000vb, 1 sat/vb), parent B (1000vb, 2 sat/vb) and child C (100vb, 20 sat/vb). You would like to replace C with newer transaction C’ (100vb, 10 sat/vb) spending parent A and parent D (1000vb, 20 sat/vb). While the ancestor score of C’ is better than C, the feerate is far less compelling and it should be rejected by the mempool. However, the low-ancestor score child C should not be mined for a while and the pin succeeds, if this scenario is correct.

An alternate approach to this problem might be to define some new (opt in) relay policy that limits the scope of descendant transactions in some way, and then only implement a package RBF policy that would interact with transactions that meet that limited criteria.

I don’t know if any opt-in approach limiting the size of the package (both ancestors/descendants) is compatible with miners incentives. I think a pinning attacker would be always able to attach an ancestor beyond the limit downgrading the high-feerate replacement candidate ancestor score.

I’m not sure if we have considered other scoring approach like best-ancestor-score of the latest generation of package transactions. I.e, if you have parent A, parent B and child C and grandchild D, and you would like to replace with new package parent A, parent E and child C’ you evaluate ancestor score of C’ against grandchild D. I think it could be a correct answer to the miner viewpoint “Which competing chain of transactions is the most interesting to include ?”. Though I don’t know if it’s fully incentive compatible.

When I commented before I did indeed mean to suggest that we’d compare our estimated mining score of the new child … However now you have reminded me of the other concern, which is that a high actual feerate (but low ancestor feerate) transaction could be used to pin a package and make it difficult to evict. I’m not sure what to do about this!

My bad about misunderstanding your original suggestion! Yes, this is my concern with it and I’m glad you agree.

Perhaps a simple, good enough approach might be to require that the child transaction’s score is better than the ancestor feerate of all the transactions that would be evicted, and the actual feerates of the direct conflicts?

I think this would be fine, definitely an improvement upon our current logic. I can’t really think of a strong attack, will think about it more.

Let’s say you have a mempool containing parent A … While the ancestor score of C’ is better than C, the feerate is far less compelling and it should be rejected by the mempool.

IIUC since we use the minimum of ancestor feerate and individual feerate, this example doesn’t break it, since we’d use C'’s individual feerate of 10sat/vB to compare to C’s individual feerate of 20sat/vB.

The natural “attack” scenario might be: A counterparty broadcasts their tx A (which we’ll want to replace). They also broadcast an unrelated high-fee tx B (50sat/vB), and a child C which spends from A and B. Since C spends from B, it has a high ancestor feerate (even though they wouldn’t be mined together), and is thus harder to replace. But since B is high feerate, it will be mined soon, so we’re probably fine.

An alternate approach to this problem might be to define some new (opt in) relay policy that limits the scope of descendant transactions in some way, and then only implement a package RBF policy that would interact with transactions that meet that limited criteria. That might be a good direction to go if our broader attempts at this problem result in behavior that’s not incentive compatible..?

I’m now pretty convinced that opt-in shrinking ancestor/descendant limits is the way to go (ping @instagibbs who had ideas about this being necessary in the future). Maybe we start allowing nVersion=3 (or whatever signal we decide) and it doubles as a signal for package RBF and stricter limits (and BIP 125 signaling would not be used for package RBF).

A few questions:

• Is it possible to have single transaction limits as well (e.g. a single transaction cannot be more than 10KvB)? If so, that seems simpler than restricting descendants based on the size of the original transaction. Or would that be a bad idea, since it would also imply fewer possible in-flight HTLCs?
• In this policy, I think we would want to require “any tx spending from an unconfirmed nVersion=3 tx must also be nVersion=3?” And if a nVersion=3 transaction has ancestors that aren’t nVersion=3, we’d use the stricter limits? Following that, I guess we would also need “any tx replacing an nVersion=3 tx must also be nVersion=3?”
• Assuming we can figure out something sensible, it seems better to have both ancestor and descendant limits? Adding descendant limits resolves the “you must pay for all conflicts” type of pinning. But adding an ancestor limit could be beneficial in resolving the “create a replacement tx with a giant ancestor” type pinning.

I’ve posted this privately in a few places, but here’s a likely incomplete discussion of the opt-in limit reduction discussion, aimed at LN/eltoo problems, but by no means limited to them: https://gist.github.com/instagibbs/b3095752d6289ab52166c04df55c1c19

“complete package” limits seem to be inherent to any usable solution

Assuming we can figure out something sensible, it seems better to have both ancestor and descendant limits? Adding descendant limits resolves the “you must pay for all conflicts” type of pinning. But adding an ancestor limit could be beneficial in resolving the “create a replacement tx with a giant ancestor” type pinning.

Yeah I was thinking in this direction as well. I wonder if we could find some super minimal use case, like a 2-transaction package replacing another 2-transaction package, and just implement that to start. I think the rough idea would be:

• some opt-in flag (eg nVersion=3, or anything else) indicates that a transaction can’t have more than 1 in-mempool descendant with no more than X vbytes of total size. Any descendant is also not allowed to have more than 1 ancestor.
• When a 1-child, 1-parent package comes in, if it conflicts with at most 1 opt-in package, allow for RBF semantics along the lines of what we’re discussing. In this case, I think we would require the package feerate to be greater than the ancestor feerates of both transactions that would be replaced (along with the total fee check, and the incremental relay fee check).

Would there be value to any layer 2 projects if something this minimal were to be implemented?

This would be very valuable for lightning. @instagibbs has explored that space recently.

A single descendant is too limiting though: in the lightning case, each participant has its own anchor output, so we need to allow 2 descendants if we apply that rule to the commitment transaction.

[1] In looking at this example, I noticed that BIP 125 as drafted seems to misstate an important check we perform in our current RBF policy, namely that we compare the feerate of a new transaction coming in to the feerate of the existing transactions that it directly conflicts with.

Perhaps we should aim for a new rbf bip that describes bitcoin core’s actual policy for both rbf of single txs and packages of txs, and document that we implement the new bip, and not 125?

To recap my thoughts:

0. I really think this direction is somewhere we need to go. The fact that in my sketches I can get rid of carveout, and naively support N-party contracts speaks to me that we’re on the right path. The fact it makes simple systems like batched payouts potentially more robust is also a win.

1. I am 99% sure we want to limit entire package limits to make rule#3 pinning not a kill shot for replacement replacement

2. @t-bast Ephemeral dust, or dust values that are immediately spent within the package, enable LN and other systems to switch over to a single anchor output, obviating the requirement for carveout rules, and would fit within the one-parent-one-child pattern.

We could expand this to two direct children limit, and preserve the carveout to make sure currently deployed systems get benefits, assuming it’s not otherwise a DoS/incentive compatible issue

3. Another nice-to-have would be forced signaling of replacability of the child tx, since the single-anchor spend is mostly freeform. We can work around this via “0 CSV OP_1ADD” scriptpubkey which forces RBF signaling, but something to consider. Full RBF solves this longer term as well.

@t-bast Ephemeral dust, or dust values that are immediately spent within the package, enable LN and other systems to switch over to a single anchor output, obviating the requirement for carveout rules, and would fit within the one-parent-one-child pattern.

:100:

We could expand this to two direct children limit, and preserve the carveout to make sure currently deployed systems get benefits, assuming it’s not otherwise a DoS/incentive compatible issue

Don’t bother if it’s only for lightning, since we’ll need a (small) change on the commitment transaction format to benefit from it, we might as well directly switch to a single anchor output.

Yes, same as here: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy

A transaction conflicts with an in-mempool transaction (“directly conflicting transaction”) if they spend one or more of the same inputs.

same as here: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy

Would it be more clear if I change the terms, or repeat them in this doc?

I believe this falls short in that the parent V3 transaction can be just south of 101kvB, even in ANYONECANPAY and SIGHASH_SINGLE like scenarios where additional inputs cannot be excluded by the presigning parties.

In imprecise language, this is what I expect to be required to solve it: “When evaluating a V3 transaction, if its total mempool package size after entry into the mempool would exceed 4000 virtual bytes, it is rejected.”

Happy to change this of course, but just want to clarify what you’re suggesting.

In imprecise language, this is what I expect to be required to solve it: “When evaluating a V3 transaction, if its total mempool package size after entry into the mempool would exceed 4000 virtual bytes, it is rejected.”

I interpret this to mean that we should change both ancestor and descendant limits to 4000vB. This also means an individual V3 tx is not allowed to be more than 4000vB by itself. So in the LN case, a commitment tx isn’t allowed to be more than 4000vB. I believe this would necessitate lowering the max in-flight HTLC limit. Is that accurate and if so, is it ok?

Your comment seems correct. Will have to think about this some more with respect to the case today.

edit: Looks like that works out to ~85 HTLC outputs or so naively in the layered commitment style setting

I believe this falls short in that the parent V3 transaction can be just south of 101kvB,

Correct me if I’m wrong, but I think this case would be something like: you’re trying to confirm tx A which pays no fees itself; your counterparty publishes a package of tx A, B and C; C spends both A and B; A and C are both small, but B is 99kvB with an ephemeral output that is spent by C. You can’t replace C without also replacing B because of the ephemeral output.

What you could do, if the ephemeral output is anyone can spend, is replace C in two steps: one that creates tx D that spends B’s ephemeral output (it’s anyone can spend), which costs you C’s fees plus epsilon; then you create tx E that spends A with your desired feerate. So you’re paying ~100kvB at the “backlog” rate here.

With a 4kvB “related txs” limit, I think the worst case setup is just A is small (100vB) and is spent by B which is large (3900vB), so you have to pay at least 3.9kvB at the backlog rate plus epsilon to replace it with something smaller, but that’s clearly already 25x better. Even if the backlog rate is not much smaller than the next block rate, you’re only overpaying by at most 39x rather than perhaps 1000x here.

I interpret this to mean that we should change both ancestor and descendant limits to 4000vB.

Hmm, I think the worst case scenario here would still be bad:

• A is spent by {B1,..,B20} (descendent count = 21 so less than 25)
• B1 also spends C1, B2 also spends C2, etc; all via ephemeral outputs
• A, Bn are 100vB each; Cn is 3800vB each

A has a descendent size of 2100vB; Bn has an ancestor size of 4000vB and a descendent size of 100vB; Cn has a descendent size of 3900vB. So the 4000vB restriction is okay.

But replacing A thus means Bn are invalid, which then means Cn are invalid due to the now unspent ephemeral outputs, which means you’re replacing 78kvB in the mempool, not just 4kvB.

@ajtowns Note that ephemeral outputs aren’t proposed here, just the anc/desc limits.

Also note that V3 descendant count is limited to 2 (i.e. a V3 transaction can only have 1 descendant), so A can’t be spent by {B1…B20}. But of course B1 could spend a bunch of things, up to {C1…C23}.

Good point that with ephemeral outputs replacing a child means we need to remove the parent as well. I’m experimenting with implementing it, and my idea was to require the parent (the one with the dust output) pay 0 fee so it can’t stay in the mempool by itself. We’d still want to prevent replacing a large volume of transactions (i.e. include it in the RBF 100 limit), but users/devs don’t have to worry about high costs of replacement since its fee is 0?

I’m thinking about ephemeral outputs but hoping to minimize the scope of this proposal. Correct me if I’m wrong, but it seems ephemeral outputs are not needed to make package relay work for LN penalty without pinning attacks. We could do ephemeral outputs as a next step - IIUC ephemeral outputs would be a “loosening” of policy rules so we could add it on to V3 rules later?

Ephemeral outputs for ln-penalty are nice but definitely a stretch goal. I’m assuming some form exists for eltoo.

Keeping inline with what is proposed here:

For eltoo purposes, there’s no reason we cannot restrict each presigned transaction to having a single input only, and only the one ephemeral anchor for spending. Whenever a proper replacement for rule#3 is figured out, the one-input restriction could be relaxed for eltoo construction, and more typical ANYONECANPAY constructions likely work after this as well.

But replacing A thus means Bn are invalid, which then means Cn are invalid due to the now unspent ephemeral outputs, which means you’re replacing 78kvB in the mempool, not just 4kvB.

To be clear, as long as we have sane DoS limits in place, to the RBF-ing party, they don’t care about these extra bytes as they wouldn’t be paying for those additional bytes(by package CPFP logic already in place, the child is already paying for parent). These further-restricted limits are not about stopping network DoS, but about pinning.

edit: Ok, the marginal DoS is there unless you ensure the dust-having transactions are unattractive to mine on their own, which 0-fee is definitely sufficient to do.

Maybe this is a naive question, but is there a way we can make that value configurable instead of using a protocol hard-coded value?

Informally, any v3 transaction would include a descendant_max_weight somewhere (handwave, handwave), covered by signatures. This lets L2 contracts decide what values are acceptable for each tx type. For example, in the anchor outputs LN-penalty case, we know that commit txs only need an anchor child that can be constrained to be quite small, so commit txs could use a low value here, that can take into account the maximum weight of a commit tx.

Or would this be adding too much complexity for only a marginal improvement? If so, we should probably bikeshed the protocol hard-coded value and use the lowest value we can to minimize the harm a malicious child tx can do.

I believe this falls short in that the parent V3 transaction can be just south of 101kvB, even in ANYONECANPAY and SIGHASH_SINGLE like scenarios where additional inputs cannot be excluded by the presigning parties.

Can’t we easily fix that by relaxing the 100kvB policy limit to be 104kvB for v3 transactions?

It’s definitely doable under an annex field regime(input commits to total package size), but it’s a question of complexity.

I do think this kind of system would allow ANYONECANPAY style contracts to be secure against pinning, so it’s definitely worth further exploration.

Can’t we easily fix that by relaxing the 100kvB policy limit to be 104kvB for v3 transactions?

You would still have to replace 100kvB of griefing txns in general, so that doesn’t sidestep the issue?

nit:

0transactions. A directly conflicting transaction and its descendants (together, "original

I was wondering whether this could be a pinning vector when used with v3 transactions, but it’s not :tada:

Packages are by default restricted to 25 elements, so in theory we’re safe, but since this value is configurable, we cannot completely rely on this protection. However, the size restriction on the v3 child ensures that it cannot be bumping 100 parent transactions, so this ensures that we’re really safe (unless I’m missing something)!

nit:

0A transaction with its `nVersion` field set to 3 ("V3 transactions") is allowed in mempool and

Or start the sentence with “Transactions with their”.

Maybe an unrelated question, but currently bitcoind doesn’t let us create a transaction that has no outputs. In the context of CPFP, transactions with no outputs can be very useful: if you have inputs that let you reach the desired package feerate without creating any change, that’s what you want to do. But currently we can’t, so we have to overshoot the input amount and add a change output.

Is there a consensus rule that disallows transactions with no outputs in blocks? If not, it would be quite useful to allow v3 transactions that have no outputs, introducing that new version is a good opportunity to do that.

Extra trivia: seems like this consensus rule has been here since the very beginning :smiling_face_with_tear: can’t believe Satoshi didn’t predict the need for CPFPing presigned transactions.

https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.h#L443-L448

Is there a consensus rule that disallows transactions with no outputs in blocks?

Yes. It’s a hard rule.

Can we relax the replacement_ancestor_feerate for v3 transactions? What would be ideal would be to simply ignore unconfirmed v3 ancestors from this calculation (some kind of replacement_non_v3_ancestor_feerate), which I believe is ok from an incentives’ point of view given the other restrictions on v3 packages.

Otherwise we will have the following issue:

• a commitment transaction pays 0 fees and weighs 19,000 vbytes (it has many HTLCs)
• an attacker publishes a CPFP v3 child that weighs 1,000 vbytes and has an individual feerate of e.g. 100 sat/byte
• the package feerate ends up being 5 sat/byte, and the package doesn’t confirm
• if a feerate of 20 sat/byte for the package was enough to get the package confirmed, the honest participant would target that and thus create a CPFP v3 child with a feerate of 400 sat/byte
• but that would be rejected under the current rules, and the honest participant is forced to make the package feerate be 100 sat/byte, which is extremely expensive

I’m realizing now that this is actually just another way of formulating @instagibbs’s proposal to evict v3 siblings: when the direct conflict is a v3 transaction with an unconfirmed v3 parent, it would be great to only compare their individual feerates.

I think we cannot do only individual replacement here, if the attacker publishes their commit + their child, and the honest participants wants to publish their own commit + their child (because for some reason they never receive the attacker’s package in their mempool so cannot attach a CPFP to that commit).

So this is actually slightly different from the v3 sibling eviction problem, which as you point out probably just works :tm: with individual replacement rules already.

I’m not yet 100% sure whether package RBF currently lets us replace [CommitTxA (19,000 vbytes, 0 sat/byte), AnchorTxA (1,000 vbytes, 20 sat/byte)] with [CommitTxB (19,000 vbytes, 0 sat/byte), AnchorTxB (1,000 vbytes, 80 sat/byte)], where all txs are v3 (which is the issue I’m trying to describe here).

I probably just need to write a test for it and see for myself, but what do you think?

I see okay so the situation is:

original transactions = commitment_A + cpfp_A replacement transactions (package) = commitment_B + cpfp_B

• commitment_A: 19,000vB, 0sat.
  • individual feerate = 0sat/vB
  • ancestor feerate = 0sat/vB
• cpfp_A: 1000vbytes, 100,000sat.
  • individual feerate = 100sat/vB
  • ancestor feerate = 5sat/vB
• commitment_B: 19,000vB, 0sat.
  • individual feerate = 0sat/vB
  • ancestor feerate = 0sat/vB
• cpfp_B: 1000vB, 400,000sat.
  • individual feerate = 400sat/vB
  • ancestor feerate = 20sat/vB package feerate = 20sat/vB

replacement_miner_score = minimum(package feerate, ancestor feerate) = 20sat/vB the rule is that replacement_miner_score must be higher than

• the direct conflict’s (commitment_A) indivdual feerate = 0sat/vB
• the original transactions’ (commitment_A, cpfp_A) ancestor feerates = 0sat/vB and 5sat/vB

So this should be fine AFAICT

This rule is still sometimes problematic if you are doing batch fee bumping.

Let’s imagine the case where we have two separate channels, symmetrical commitment transactions(for clarity of argument).

If commitment_A is in the miner’s mempool, and Bob wants to fee bump commitment_A as well as CPFP commitment_B(different channel!) into the miner’s mempool, Bob will have to pay the replaced cpfp_A’s feerate for the entire CPFP commitment_B + cpfp_B package.

In other words, batch bumping is probably not a good idea unless you know package RBF will evict the sponsored transaction directly.

nit:

0/** Maximum virtual size of a tx which spends from an unconfirmed V3 transaction, in vB. */

“evicted in the event of a replacement” is a tautology, it’s being replaced so obviously it’s being evicted.

suggested: “in the event of mempool entry of the new transaction”

The pinning “damage” is specifically bounded between the tx size of whatever an honest user would have needed to make to bump, and the total allowed limit. For example, if a wallet only needs half the space for an honest fee bump, an attacker is bound to a 2x fee pin attack, maximum, instead of 200x without V3 rules.

Might want to mention that it bounds the economic damage by ~100x in a digestible form.

to belabor the commit text:

“Transactions could conflict with the same tx”

meaning transactions in the same package can conflict with the same original tx, so for package evaluation, we only want to count these once?

no results are being pushed here, which seems to mean we’ll hit NONFATAL_UNREACHABLE in the switch statement in submitpackage RPC with a tx that doesn’t hit the above two conditions.

e.g., a non-standard script

This incentive deficiency linked above should be a non-issue for CheckMinerScores since V3 package RBF is a restricted topology which disallows an multiple ancestors entirely.

The two cases of “adding a new unconfirmed input” during RBF with this PR:

1. Package size of two(no dedup), new CPFP child is RBF’ing another (set of) tx, goes through CheckMinerScores
2. Package size of 1(deduped parent), transaction is rejected via single-tx-acceptance rules currently in master. Perhaps a constrained V3-only version of #26451 could remove the pin?

The asymmetry above is annoying and a mild pinning vector.

As of this PR, wallet authors can avoid this pinning scenario entirely by not moving fee utxos between different unconfirmed parents, but it would be nice if asymmetry was avoided to make wallet reasoning simpler.

This should precise if the mempool conflicts are required to be V3 themselves. From my memory of the mailing list discussions and elsewhere, I think the current state of thinking, directly conflicting transactions versions number are not considered.

For the Lightning use-case, this is a significant security advantage as the ~80k of public channels, with all pre-signed revoked commitment transactions V2 can be replaced with newer version=3 package. Revoked commitment transactions, even if the honest counterparty is in knowledge of the revocation secret, are still consensus and policy valid transactions, and as such can be leveraged as pinning means.

On the other hand, I think allowing V3 to replace V2 chain of transactions lead to the consequence than V2 users are implicitly subscribing to this new replacement regime. A receiver of a V2 transaction could apply the BIP125 rules to estimate the replacement odd of the transaction, and the application logic be broken when the actual rule 3 of minimum between package feerate and ancestor feerate is applied. I don’t know if we’re significantly interfering with any Bitcoin application here.

I think allowing V3 to replace V2 chain of transactions lead to the consequence than V2 users are implicitly subscribing to this new replacement regime. A receiver of a V2 transaction could apply the BIP125 rules to estimate the replacement odd of the transaction, and the application logic be broken when the actual rule 3 of minimum between package feerate and ancestor feerate is applied.

I’ll try to be more vocal that V2 transactions can be replaced by V3 transactions. The cost of replacing a V2 transaction being replaced is identical (or higher, given the ancestor feerate rule) - the fee must be paid, but it can be by 2 transactions instead of 1. So, while there is a “new” way to replace, the “likelihood” of a V2 transaction being replaced is the same or lower.

If we would like to add more rational to the design of the rules, we could explain why a scorched earth approach would solve the Lightning case really imperfectly (discussed recently here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html). Indeed, Lightning implementation could just blindly replace-by-fee the pinning transactions, paying up to the channel value. This wouldn’t work at all against an attacker pinning with one single malicious transaction multiple channel from different parties where the malicious transaction fee is above the value of each channel. E.g channel A 10000 sats, channel B 25000 sats and channel C 8000 sats. If the malicious pinning transactions fee equals 26000 sats, none of the honest party will rationally fee-bump more than their own channel value.

Feerate-only replacement rules scales up to the maximum package size and worst historical mempool reduce consideraly the fee-bumping reserves requirement for a LN node, which is a notable advantage I think.

It would be evicted as any package-limit-breaking transaction.

In the case it’s evicted, you have to consider LN V3 package being evicted and as a LN node you should resuscitate the V2, fee-bump it again, wait for confirmation and then re-broadcast your V3 package.

I’m not sure application-level detail like this is helpful in the document unless it’s a high-level principle.