Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

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.