V3 transaction policy for anti-pinning

If enough people are paying fees out-of-band for ephemeral anchors that we believe it’s threatening mining decentralization, our choice would be to either activate an easy and laser-focused soft fork or to lose mining decentralization. Given that choice, I think there would be widespread consensus.

hmmm not sure about this extension, sometimes the best thing to do is just burn the ephemeral anchor value by itself, which results in a 65 vbyte txn. I think in the end it’s the same risk as people paying transaction accelerators so they can use fewer inputs in an RBF?

I think the expected use of an ephemeral anchor would be:

  • Parent: 1 input, x+1 outputs. The +1 is the ephemeral anchor.
  • Child: >=2 inputs, >=1 outputs. One input is the anchor spend; the other contributes fees.

In the pathological case, the parent is the same but the child is never created. So we need a requirement that spending the parent can only be done at a cost equal to at least 2-inputs and 1 output.

That requirement doesn’t need to be an input requirement; it could also be treating a childless parent as if it had the additional weight of a 2-input, 1-output child.

But as per Peter Todd’s tweet miners can just efficiently spend all the anchor channel outputs together in a block. More efficient than any normal CPFP. It’s still more efficient to pay out of band too because UTXOs for the ephemeral txs need to be created and spent. Vast majority of channels will be stuff like Phoenix in the future, which want one UTXO per user. Can’t anchor that.

1 Like

Backing up a bit:

How is this decentralization argument not generalizable to any BringYourOwnFunds(BYOF) scheme?

For example, presigned HTLC-X transactions?

These are batchable. They are cheaper to be paid out of band.

Are we really arguing against all exogenous fees in smart contracts? I reject the premise entirely.


Link to what a HTLC-X transaction is?

@instagibbs is talking about HTLC-Success and HTLC-Timeout transactions as defined in BOLT3

These are presigned spends of HTLCs made with SIGHASH_SINGLE|SIGHASH_ANYPREVOUT that allow multiple of them to be combined into a single transaction. The don’t contribute any fee (or any meaningful fee), so we would normally expect them to be combined with an extra contributed input that adds fees (and likely an extra output for change). However, the threat-to-decentralization argument, you could pay a miner out-of-band fees to mine them without adding an extra input or output, saving block space.

I made this same argument to PT last night (last paragraph): https://twitter.com/hrdng/status/1743293516992876561

He almost doesn’t even address it.

“As for SIGHASH_ANYONECANPAY, obviously, it is still a problem, which is why I mentioned, among other mitigations, that in the future SIGHASH_ANYPREVOUT would help the situation.”

Again, does he believe that all future smart contracts should have endogenous fees, otherwise we’re risking decentralization? Is that really a tenable reason to stop any proposal(aside from the ~50vb that ephemeral anchors costs)?

“Obviously scale matters. We can’t prevent every single circumstance where someone might want to pay a transaction out of band. But we can and should design protocols to minimize it.”

That seems to cover it. His article that started all this proposes a few solutions for HTLC-X problem too: V3 Transactions Review

That’s a fair point; it does undermine my claimed advantage of a soft-fork version of ephemeral anchors.

I haven’t thought of an alternative way to obtain the property of in-band CPFP fee bumping pay the same weight cost as out-of-band transaction acceleration, at least not without preventing batching that would be beneficial to users.

That’s an argument for specs to avoid exogenous fees when possible, not how to make sensible mempool designs. if your smart contract can have endogenous fees, you should consider it. That’s appropriate! But this is not the case in many(most?) protocols outside of ln-penalty, and it’s completely inappropriate to gatekeep good mempool design to a specific instantiation of a specific idea.

Please see motivation/use-cases sections for more details on what kind of smart contracts V3 and ephemeral anchors is useful for:

Lastly, if “scale matters”, then we should be doing everything in our power to make fee bidding useful. No one has put forward an alternative proposal that makes sense for many RBF like V3. This has been years of discussions, and based on Peter’s writeup I don’t think he bothered to read my BIP draft.

This stuff IIUC is only talking about signature complexity and providing fees? As a humerous aside, HTLCs are endogenous fees(decentralization hit!), and would be more pin resistant using ephemeral anchors, but I’m not pushing for that in my proposal spec because of relative spec diff(HTLC-Success paths on both commit txs would have to be pre-signed, really hairy given the duplex updates it has now) :slight_smile:

Note that similar OOB benefits are obtained by batching and SIGHASH_SINGLE|ACP-based smart contracts today, and would be similar if we had any good introspection opcodes.


is there a reason to necessarily allow more than 1 unconfirmed ancestor for an ephemeral anchor type fee bump transaction?

if only the anchor itself is unconfirmed, what mempool pinning tactics are possible?

I mean, it’d be nice for batched CPFP! There are no known designs to do that that are pin-resistant though.

not entirely sure what the question is, mind rewording?

1 Like

that’s what i thought. so first we could just allow for a more restricted and less efficient way of doing ephemeral anchors. but at least we would have something usable that is easy to implement and reason about. then expand later to more useful and more optimal ways of doing it?

1 Like

I’m trying to better understand the claimed v3 pinning vulnerability. Do I understand correctly that:

  1. The worst case, which is what PT analyzed, is a commitment transaction with no pending HTLCs.
  2. The attacker reduces the feerate of the package/cluster containing the commitment transaction by the attacker using their own money to pay the fees.
  3. A commitment transaction with no pending HTLCs has no special urgency (i.e., no timelocks that will expire to the detriment of the broadcasting party).

In other words, the worst case form of this attack would be that Bob will have to wait a bit longer to respend his channel funds but Mallory will pay his fees?

Obviously, the attack also works against commitment transactions with pending HTLCs, but for each additional HTLC output, the attack quickly becomes less effective due to the decrease in relative size difference. Perhaps more interestingly, if Bob pays out of band to fee bump both the commitment transaction and Mallory’s pin (ephemeral anchor spend), Bob will possibly pay less fees than he would’ve without the pinning attack and Mallory will end up losing the funds she spent on the attack.

Of course, paying to defeat an attack out of band is still bad for mining decentralization, but I think all of the above points to this pinning attack being possibly ineffective.

1 Like

yeah, protocol and wallet devs should be reluctant to rely on oob payments to resolve mempool conflicts or timeout situations. such an api is a single point of failure and a huge centralization vector.

not gonna pretend i fully understand the various pinning attacks, i expect the major pain would be when you try to settle some contract by adding fees through the anchor, and someone else outbids your tx with higher fees (which is not a problem for you in itself) but with dependence on other unconfirmed ancestors, which ancestors they can double spend, resulting in the eviction of both fee bumps and the anchored tx from the mempools.

I don’t think that works: if you get to the point where miners offer an API for out of band fee payments that’s trustworthy enough and discounted enough that it sees wide adoption, leading to a centralisation risk, then if you did have a soft fork to require ephemeral anchors be spent, then those miners could work around your soft fork as follows:

  • create a “nouveau ephemeral anchors” BIP, with the same behaviour as before the soft-fork, but with a different scriptPubKey pattern
  • flood the network with nodes that relay according to the new BIP, have those nodes preferentially peer with each other to ensure there aren’t disconnected subgraphs
  • get this implemented by the devs that had already integrated with their API
  • push the patch to core noting that it’s in wide use on the network
  • profit

I think the sort of soft-fork you be okay if it was in line with economic incentives (ie, the only time an ephemeral anchor is in a block but not immediately spent is people testing things on regtest/signet/testnet, or due to bugs), but if the economic incentives are strongly pushing the other way (miners, wallet devs and users all collaborating to save a buck despite the centralisation risk), I don’t think a soft fork here would actually help.

(The other soft-fork approach would be: “an ephemeral anchor output can only be spent in the same block that it was created; it’s removed from the utxo set once the block is completely processed”. That resolves the “bugs lead to dust in the utxo set” issue, but doesn’t touch out-of-band-payment incentives, and introduces the potential for the child tx to become invalid in a reorg, if for some reason it isn’t included in the same block as its parent)

1 Like

I think you’re mostly describing the “cycle attack”, where the child is RBF’d out of the mempool, and the new child no longer spends the ephemeral anchor, causing the parent transaction to be evicted.


Mitigation is, in general, to aggressively re-broadcast, since each cycle costs the attacker fees(unlike pins).

You can think of it in another, imo more principled way: Someone is paying toe censor you, but they have to continuously bid block on block(and inbetween blocks if you’re doing it right + mempool synchrony assumptions), where you only pay once at the end of the game at most, and at your expected rate.

I don’t want to get too deep into cycle discussion though; it’s been done to death.

1 Like

Just checked. At the moment the fees required to get into the next block are 30sat/VB while the min relay fee is 22.2sat/VB. The mempool feerate is super flat. So an attacker could easily force you to wait basically forever becuase those min fee txs aren’t gonna get mined, unless you pay the 50% extra. Not good. And the attacker’s txs will get pushed out of the mempool as fees go up so Mallory isn’t paying anything to attack.

HTLC outputs aren’t much more space. I don’t think Peter’s numbers would change that much if you did the computation for that case too. You could do the same attack on the HTLC as well I think?

@glozow How are V3 transactions supposed to work with HTLCs anyway? Going to have V3 HTLC-success/failure transactions too?

Hmm, so Peter’s thing made assumptions about the attackers fee margin of error that aren’t valid right now. His analysis assumed the attacker paid 1/2.5th of the victim fees, which would be less than minrelayfee. You could probably get away with just 25% less right now, which would force the victim to pay 2.8x more fees. Big difference!

1 Like