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. 
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
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.
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.
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.
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.”
That seems like a more clear articulation of what you're arguing for.
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.
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.
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.
...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.
