Nostr Web Client

Can you elaborate a bit on the Phoenix example? Is it actually holding on chain funds in reserve in case it needs to CPFP? It probably should, but how is that worse than with other nodes?

Sjors Provoost 2y ago

I'm also not sure if I follow the out-of-band economic logic.

Let's imagine blocks fit exactly 10 transactions and they're all equal size. Alice needs to get their closing transaction in on time and has two options:

1. Use CPFP by paying a fee rate based on what the mempool shows, such that the combined child and parent make it into slot 9 and 10.

2. Pay the miner out of band to get the parent in slot 10, without a child transaction.

A miner would only do this if they can earn more than the fees in slot 11.

So it depends on the slope in fees. In a high fee environment I would expect this slope to be fairly low at the 4 VMB edge. But haven't run the numbers.

Reply to this note

Please Login to reply.

Discussion

Sjors Provoost 2y ago

Trying to answer my own question... in v3 the parent pays 0 while the child pays the price of two slots. The opportunity cost for the miner to replace slot 10 with the 0-fee parent is simply the fee of the transaction that would otherwise be in slot 10.

So as you point out, they could charge out of bound anything between about 50% and 100% of the child fee. Slightly less because of the slope in fee rate, that effect is tiny.

Peter Todd 2y ago

Exactly.

The slope of mempools is very flat, so the opportunity cost of the child is very close to that of the parent.

#m=image%2Fjpeg&dim=1920x613&blurhash=Q6C%3DML%7D%23A%23%3D-E%3B%24aNjnwxe0CE-%3DvE-%24yI%5EsQR%3AW916SRxWS8s%2BNMavWGWS&x=c15fd1db4a68c7cbefc8f6bb7cf7530385827cb9d7f14b293036fd5658e1e9d6

Sjors Provoost 2y ago

How much worse do you think ephemeral anchors are (incentive wise) than the current dust-anchors? At first glance I would think the 546 sat difference is insignificant in a >200 sat/vbyte environment.

Meanwhile 0-value outputs reduce complexity and afaik are essential for ln-symmetry.

One final point: regarding recommendation 3, I don't think anyone would want to move forward with v3 without ephemeral anchors.

Peter Todd 2y ago

All anchor/CPFP schemes have this problem. I singled out ephemeral anchors because they haven't been shipped yet; we should be phasing out anchors entirely whenever possible.

It's true that I could have gone even farther and argued that we shouldn't have CPFP or package relay at all. But I think arguing against CPFP is hopeless; arguing against package relay might be worthwhile still.

A problem is lots of more complex L2 protocols that people are excited about seem to need package relay. But maybe that's not true; I haven't thought enough about those details to be sure.

Peter Todd 2y ago

And yes, maybe someone will come up with a way to modify V3 to make it worthwhile. But I agree that without ephemeral anchors the idea doesn't make sense.

Even with ephemeral anchors, for Lightning it's really not _that_ much of an improvement. The second anchors output in anchors channels is redundant. So if we get rid of that, the only savings in ephemeral anchors is the size of the signature/checksig, and that reintroduces tx pinning unless V3 has the tx pinning problem truly fixed.

https://petertodd.org/2023/v3-txs-pinning-vulnerability

Peter Todd 2y ago

How about I change #2 in the “Recommendations” section from:

“Ephemeral outputs should be strongly discouraged due to the above-mentioned miner decentralization risks; support for them should not be added to Bitcoin Core.”

to:

“Existing usage of anchor outputs should be phased out due to the above-mentioned miner decentralization risks; new anchor output support should not be added to new protocols or Bitcoin Core.”

Sjors Provoost 2y ago

That seems like a more clear articulation of what you're arguing for.

Sjors Provoost 2y ago

Last time I (briefly) looked at the relevant Bitcoin Core PR's the sequencing was:

1. Package relay for n=2 (1 parent, 1 child)

2. V3 transactions (including ephemeral anchors)

3. Cluster mempool

4. n>2 package relay

This sequence is not set in stone:

(3) and (4) don't require (2)

(3) does not require (1) and (2)

But n=2 packages is special in that it's less complex and is sufficient for v3 transactions.

In other words: if you want to argue against package relay, soon is a good time.

https://github.com/bitcoin/bitcoin/issues/27463

Peter Todd 2y ago

Indeed.

I'm doing an analysis of covenant dependant layer two protocols right now, which I'm trying to finish ASAP, so I should have a better understanding of the issue soon.

Unfortunately the answer might be that there's no good answer.

Sjors Provoost 2y ago

Indeed there may not be. If (CPFP) packages are incentive compatible, then not supporting them in the p2p protocol creates and incentive to submit them out of band.

But having the p2p support also makes more obvious that out of band payment might be cheaper than sending the whole package.

Peter Todd 2y ago

...and the code for CPFP is already written!

Most important thing is to fix protocols to use better techniques. We're fortunate that RBF is about half the cost of CPFP in most cases.