Oddbean new post about | logout
 Thanks for the article link. I don’t agree with the concept that we should have some goal to “never add any risk to bitcoin” because there’s no such thing. 

Not having critical primitives for scaling sovereignty is absolutely a risk. Not enabling ways to create more expressive layers is a risk. Adding additional locking types and designs is a risk. Adding introspection is a risk. Everything has risk. 

There are no solutions, there are only trade offs. The day we forget that, we lose our ability to make an honest assessment of anything. Bitcoin is not perfect, it’s simply the best we have. 
 Glad you brought this up. We should definitely go through these points and possible solutions, though it will take some time—probably weeks or months—to cover everything in detail.

On risk, I think the biggest threat to Bitcoin is a fork and chain split, even more than a 51% attack. We've never had a 51% attack, but we've seen multiple forks and splits. Any new feature has to be worth that risk, and it should be explained clearly enough that at least 10% of users can understand it from first principles.  Let's keep in mind the real dangers of a chain split.

Right now, I don’t think we’re fully using the tools we already have. I monitor testnet4 closely, and it’s clear that Bitcoin + Taproot (which ties into Nostr) isn’t being used much. Sometimes my transactions are the majority in a block.

What do you mean by critical primitives for scaling sovereignty? One trade-off could be that Nostr npubs and Taproot addresses offer sovereign ownership and property rights, whether on the base layer or something like Liquid. We’ve barely scratched the surface of using the (u)txo model for a chain of custody, like with single-use seals. A decentralized free market could be built on Bitcoin with this, but I’m not sure there’s much appetite for it right now—especially for niche use cases like vaults that no one’s really asking for. 
 “critical primitives for scaling sovereignty”

Basically anything that allows non-interactive (and private) splitting up of UTXO ownership.

Basically it’s inevitable in the future that every single UTXO is not a single address with a single owner, but that every single UTXO is its own network with many hundreds or thousands of owners.

If we are thinking about design with that in mind, I think we are making a mistake. 
 If we *arent* thinking about design… I suspect that was obvious but autocorrect has been killing me recently, so just in case. 😅 
 Got it, that makes sense. But we also need to see real demand for these features to justify any urgency. If there’s genuine demand, it could be shown on Liquid or Elements first, and the user base would say, 'Yes, we need this.' The same goes for a solid self-sovereign identity or trading solution—it should be tested on testnet, even with some workarounds. Creating a false sense of urgency risks dividing the community and causing a chain split, which we've already been through, and it was almost fatal. But, nobody cares when you only get shot in the ear!  :) 
 We already have the proof of use-case, imo. It’s custodial Lightning. Wallet of Satoshi could offer the exact same service with just a CTV pool in the most naive sense. And then if WOS ever vanished, literally everyone could redeem their coins still.

All we need to prove this viable is demand for people to use custodial wallets and assume they don’t want to be rug pulled.

Also, I’m not trying to make a sense of urgency here, just to explain. I don’t even think there is a rush, I just think CTV is basically just waiting for there to be a clear line in the sand for people to decide about. 
 Thanks, that’s helpful. My take is that we should really push single-use seals to their limits first. It’s a Layer 2 solution based on (u)txos, and like with Nostr, once people see what’s possible, they’ll get it. Single-use seals might not be perfect, but they’re likely better than Tether, and people use Tether. It’d be great if folks used and tested the tech we have before asking for more features or forks.

We’re also assuming sovereign identity is just for humans, but maybe machines will use Bitcoin more than humans. We need to see how things play out to make the right trade-offs and keep in mind the risk of catastrophic failure—like a chain split. Remember, there are vested interests that might actually want a split. A fork needs both social and technical consensus and has to be something the user base, many of whom have entrusted their life savings to this, actually wants. 
 Yeah for sure, I think we’ve also barely scratched the surface with what we can do regarding the tools we already have and there is certainly a focus on “with this next thing we can do X” instead of working with what we have. It’s easy to get caught up in the “next thing.” 
 But that’s actually one of the reasons I think CTV would be so valuable. I think I could feel like the trade off to ossification after CTV isn’t that bad. Right now the risk of ossification is a net negative, imo. And plenty of people think we need far more than just CTV, while some argue we should ossify now.

I fall in the middle. I don’t hate the idea of ossification because of what I just mentioned, however I know that CTV opens up a lot of possibilities and we could still be figuring out really awesome constructions for things even a decade down the line if we had that primitive. 

In other words, I’d feel like we have a much easier path to the future we want even if we ONLY got CTV before it ossified, and it would be low risk enough that I wouldn’t have to worry about having gone too far either. 
 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. 
 Very smart thinking , thank you 🙏  

What people would want indeed ? Thats the question ! 

For me on #nostr for example, #zap has been the main feature by far, unlocking p2p content business model 👀🔥🕺