Good point. We’re still aiming at a moving target. In the next four years (the next epoch), we could see AGI emerge, which could change everything—how chains are used, how development happens, how we discuss things, and the path to ossification. Once AGI arrives, we’ll likely get used to virtual assistants that communicate on new layers, invent tech we haven’t seen yet, and do all this without needing forks.

We’ll be able to evaluate things like the mining fee auction more efficiently, figure out things like the nash equilibrium and iterative prisoners dilemma e.g. how much will a high value tx pay to get priority.  All our research and explanations will get a big helping hand. 

The app landscape for consensus and polling might shift too. We’ll be able to replicate the best parts of DeFi on Bitcoin, Nostr, Ditto (maybe Pear too), and we’ll be better at identifying and countering social attacks. The future could be pretty interesting, and we're not in a rush for a killer feature or osification I dont think immediately.  We do want to avoid catastrophic failure vectors, and guide the project carefully through the next phase. 

 I think this was a very productive discussion. Thank you. 🙏 

My position is that the rush to solve scaling is premature. Changes to the protocol must be both safe and necessary. 

There is a debate over CTV’s safety and many devs acknowledge some risk. But what about its necessity?

Do we have an existential scaling problem today? As I type, the mempool is clearing at 3 sats/vbtye. 

I’ve seen no evidence that normies want self-custodial bitcoin right now. It’s funny because @utxo just shared a meme on how normies want centralized apps where they can sign in with Google:

nostr:note1ejc68g2p2cdq32vlw52de9dcfqfzvy28m4ywnhqffxt7e5rg6hjs3ycj2p

You want self-custodial bitcoin, I do too. But I’ve seen NO evidence that bitcoin is failing to grow because of an inability to scale or that CTV, CAT or anything else will “fix” whatever future problem we might have.

We can’t “solve” problems that don’t yet exist. Especially if we’re taking a risk to the bitcoin network in doing so. 

Maybe you’ll be right and there will be an existential scaling problem someday. If there is, the best minds can solve it then. Isn’t premature optimization one of the worst “crimes” in computer science? In the meantime, we should continue to do research and test out options on other layers so we’re ready for what the future brings. 

There is no ossification “now or never” line in the sand unless you believe C++ coding will somehow be lost to antiquity. 

Devs arguing that they need to push this through quickly while they can is just an indictment that they believe that they have some power now that they won’t have later. Those devs believe they should have the governance power and not the nodes. This is a power grab, and an attack on the network. 

 • never said there was an existential scaling crisis
• my goal isn’t to fix future problems, but current ones. Most bitcoiners are using custodial lightning for #nostr not because they don’t care, but because you can’t do non-interactive push payments over lightning. With CTV you could. That solves an immediate problem for the very people who DO want to be on a bitcoin standard… to be blunt, I honestly don’t care about normies who want centralized services.
• ossification isnt about whether there is c++ code or not. It’s just a point we get to where the barrier to consensus is too great. (example IPv6) We may have literally already reached it if merely judging by the conversations around these things.
• devs aren’t trying to force anything from what I’ve seen. To the contrary they are afraid to make any moves at all. Which is why I felt a specific CTV client for noderunners would be the reasonable path. 

 Do you really believe that bitcoiners are using custodial nostr apps only because the interactive push payments?

The custodial apps all offer better UX across many aspects: free, no upfront capital cost, better routing, ongoing liquidity management, etc. 

If there was a current problem, and we needed non-interactive push payments, we would see many people using Mutiny and using offline receipt and forwarding services. But we don’t because Mutiny was the best non-custodial app I’d seen but still didn’t have product-market fit.

Said another way, if we snapped our fingers and solved the push payments tomorrow, we still would have almost nobody using Mutiny. Lightning’s UX issues are much bigger than that. 

 “Do you really believe that bitcoiners are using custodial nostr apps only because the interactive push payments?”

Yes, absolutely. When we started out over here, lots of people were using non-custodial but trying to explain to people how to receive payments was frustrating, and you couldn’t just post an address and have it work. Even most of the people who were using non-custodial ended up switching over to get a Lightning address, myself included. 

I watched it migrate in real time. The inability to post an “address” and receive a zap was THE reason the overwhelming majority went custodial. 

 Mutiny had other problems mostly because it was a browser based wallet and was always on the struggle bus, Phoenix and Breez (and those I’ve used with Breez SDK) have worked fantastically. Phoenix was better than basically any of the custodial options I used. Would have never switched away or even used anything different had Lightning address not been an issue, and then of course them leaving the US App Store so I can’t recommend them anymore. 

 That doesn’t make sense to me because it seems custodial lightning was preferred by plebs even *before* nostr existed and even *now* when there is no need for offline receipt. Like in El Salvador or Costa Rica, for everyday retail payments. Last I saw, WOS and Bitcoin Beach / Blink, were preferred before nostr, and probably still are. For your argument to be correct, I would expect to see widespread and growing self-custodial lightning usage in those communities. 

Am I wrong about that?

You might be right that the early nostr adopters were all using self-custodial lightning, but surely you’d agree that is not a representative sample of plebs. As nostr grew, it was probably destined to become mostly custodial because of the existing preference of plebs.  

I don’t know what percentage of lightning usage is custodial but I’ll bet that by almost any metric it will be custodial by a large and growing margin. 

Maybe this is unpopular, but my current thesis is that self-custodial lightning will become used only by federations, exchanges, and other custodians. We, the plebs, will all migrate to ecash, presumably to large geo-federations when they exist. I’m just guessing here, but that’s the trend I see right now. 

 “That doesn’t make sense to me because it seems custodial lightning was preferred by plebs even *before* nostr existed and even *now* when there is no need for offline receipt. Like in El Salvador or Costa Rica, for everyday retail payments. Last I saw, WOS and Bitcoin Beach / Blink, were preferred before nostr, and probably still are. For your argument to be correct, I would expect to see widespread and growing self-custodial lightning usage in those communities.”

You aren’t listening or I’m not explaining precisely enough:

I didn’t say non-custodial was generally more popular, then it suddenly wasn’t. I said **bitcoiners who wanted to use non-custodial** and *who even tried* for some time, couldn’t do it because of the inability to receive while offline and the inability to have a compatible static address without a web server.

And yes, that was a real thing. Like I said, even I am using custodial for zap receives because of this. 

 Thanks for the commentary, Guy. Peter didn’t say much about CTV, but he did hint it’s his preferred option. You've highlighted some use cases like batching, which is great. But we also need to discuss the risks, like a potential chain split or unintended consequences. Maybe they should test it on Liquid, create a mock Lightning network, and show some cost stats. We’re not ossified yet, but jumping straight to mainnet might not capture full support. There’s definitely been some progress with Peter’s article.