Do you disagree with his numbers and prospects for UTXO ownership?

My thoughts here are definitely unrefined, but I am sceptical of the "onchain rush solved by covenants" argument.

1. You're assuming fee volatility. I expect this to reduce over time, as regular Bitcoin usages adapt their behaviour and smooth fees

2. You're assuming wallet infrastructure which is pre-built to handle this case.

3. You're changing the deal, so the *recipient* now pays fees. If you shape things as payment trees, the tradeoff gets worse (approaching twice the weight of just paying normally, requiring that much fee volatility to make sense), and you introduce games between the recipients to figure out who pays fees.

4. You have created a novel financial instrument on fee futures, not something I accept as a "payment", as I have not received it, and you've offloaded an unknown level of costs to me to "collect" it.

5. In real bankruptcy, this is *not what you want*. You don't want your funds stuck on chain. Many might want theirs transferred in one tx to Coinbase. Others will want payment over lightning, or fiat.

6. You can do this badly, today. You can publish a zero-fee tx which pays everyone, or even a tree. That at least proves you have the funds, and can be seen by existing wallets. This, of course, requires the mempool changes which James complains about.

In summary, I don't see congestion trees actually being used: certainly not for this bank-run-in-high-fee scenario.

nostr:nevent1qqs83jwmj5g4fnqa94s5nnztnwje3v4kf4wgyyv7w4dss6njvznne0cpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qrqsqqqqqpn6m7kw

I would go one step further and suggest that when someone is throwing mud and demanding action towards a specific choice, this is evidence that the choice is the wrong one. Emotion can be a signal of commitment, but a brief survey of history demonstrates it can easily be used to make people to act against their own best interests.

Good choices tend to be based on well reasoned arguments that recognize root problems and the compromises of a decision. If something is important, it's worth putting in the effort to make good decisions.

mempool policy is referring to datacarrier or something else?

what surprised me was how Core leaned on nonsensical "disputes" to justify their inaction (well over a year now).

either fix datacarrier or remove it. The discussion of endless cat and mouse game possibilities for data storage, or the distraction of how mempool policy could induce out of band tx behavior, all that nonsense, is all irrelevant and should happen elsewhere

id imagine most users are fine with Core's mempool policy as it stands provided the available configurations actually works (it doesnt). i dont think mempool policy is a distraction at all because it is hard to determine the effectiveness of available scaling solutions if basic things like this are broken.

running through another softfork for the sake to add any new set of op_codes (which are available to use on Liquid already ) is irresponsible

Thanks for sharing your thoughts on nostr. I value your opinion and am glad to have it here.

> we’re still really far from having any particularly good ideas on this front.

Hard disagree on this, though. There are many proposals that pass muster, IMO. I favor LNHANCE which combines LN-symmetry and covenant capabilities. I am confused why you would characterize this as not a particularly good idea. You know better than almost everyone what a massive upgrade LN-symmetry would be.