Peter says:

“Unlike OP_CAT, CTV doesn’t appear to raise much risk of unintended consequences beyond encouraging out-of-band fee payments in certain cases. This isn’t ideal. But no-one has come up with a widely supported alternative.

My personal recommendation: do a consensus cleanup soft-fork, followed by CTV.”

Peter admits it creates risk, but then claims omniscience to state that the risk is minimal.

Activate OP_GFY instead!!

ADD NO RISK TO BITCOIN. You have no right to gamble with the world’s money, and our hope for the future.

nostr:npub1h8nk2346qezka5cpm8jjh3yl5j88pf4ly2ptu7s6uu55wcfqy0wq36rpev … another dev admitting that it adds risk. nostr:note1nwvrh2eqf902vjel2t0hr2hftftrz8rxe4pmlp0m2rlef8dzh8mq54fuqp

Reply to this note

Please Login to reply.

Discussion

Agreed.

While I think that Bitcoin will survive the potential risks of CTV, I never liked the idea of increasing unknown factors.

Perhaps I am wrong in my opposition to CTV and perhaps CTV might be overall beneficial for Bitcoin. Still, we need to think adversially regarding potential risks that could be used to harm the network.

1. Expanding the scripting capabilities. We can expect pros and cons here and it is hard to foresee what these will be.

2. The possibility of creating closed whitelisting loops.

After thinking the second point through over the last few weeks, I am no longer concerned with this scenario. Yet I will share my general thinking process of why I have changed my mind.

As for point 2, if I were to steelman the pro-CTV position, we could argue that all functions that improve security for decentralized Bitcoin users, also can be used by governments to increase the security of government-owned bitcon.

What secures *our* bitcoin as liberty advicates also secures government owned bitcoin, and vice versa. This is an unavoidable and fair situation that benefit Bitcoin.

A hypthetical worst case scenario:

The US, Canada, EU and Australia joins together to prevent bitcoin withdrawals from all exchanges within their respective jurisdictions.

This would not impact the Bitcoin network and sovereign Bitcoin users, but a lot of customers at exchanges would suffer.

Let's say that in this tyrannical scenario, the users of exchanges are only allowed to withdraw their capital in the form of CBDCs, while the exchanges end up holding the exchange-stored bitcoin.

We could then formulate multiple strategies for this alliance of the US and its partners to keep the mentioned exchange-stored bitcoin from being returned to their rightful owners.

One strategy could be via multi-sigs, which of course already exists. If a multi-sig requires signatures from both the US, Canada and the EU, it could be hard to overturn this decision via changing the laws in a single jurisdiction such as the US or the EU.

Another strategy could be to lock in the exchange-stored bitcoin into an unbreakable whitelisting loop, where the US, Canada, EU and Australia all include each other's addresses in a closed whitelisting loop system. If the government of the US is sued and ordered by the supreme court to give back user's bitcoin, it may not be able to.

On the other hand, if this were the case, the US could be forced to buy new bitcoin from the market in order to satisfy customer demands. This would make the whole closed whitelisting loop pointless, apart from it being ineffective from a global trade perspective.

It seems to me that my previous concern over closed whitelisting loops is not valid since it cannot function as a strategy for governments to abolish private property rights of bitcoin users.

My conclusion therefore is that closed whitelisting loops cannot become a threat to Bitcoin.

I am still critical of CTV, but less so than before.

Yes, and arguably any forced whitelisting makes non-whitelisted bitcoin more valuable. It’s terrible for people in those jurisdictions but doesn’t affect the bitcoin network as a whole.

I believe devs should follow the principle of, “first, do no harm”.

If there is potential risk, then we need to find a different way. Nobody can assess the magnitude of the risk.

We need to think long term and protect bitcoin for future generations.

Absolutely.

What solved my critique of the risk of whitelisting loops was when I considered that a court may force exchanges to return user-owned bitcoin - even if that means buying new bitcoin from the free market at a higher exchange rate. This makes the strategy of closed whitelisting loops completely toothless.

“If there is potential risk, then we need to find a different way.”

There is such thing.

Again I agree with the sentiment of extreme conservatism, but not to the point of losing touch with reality. Just the very nature of a soft fork, even with the most mundane and neutered change we could muster, is a serious risk.

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.

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 👀🔥🕺