Oddbean

Op_vault is more limited and specifically designed to enable that one feature: vaults. This article discusses vault as a subset of ctv. https://www.coindesk.com/tech/2023/02/28/proposed-bitcoin-vault-feature-could-thwart-malicious-hackers/ But the fact that vault is a subset of CTV is not my point. My point is that changes to the core protocol should be specifically limited in scope so that we can have more certainty that the change is technically safe, and also doesn’t disrupt the network ecosystem. Maybe op_vault is the right approach to solve vaults, or maybe not. What makes it better is that it’s *specifically* designed to solve vaults. CTV can be used and abused in more ways, including ways we don’t yet know.

I completely get the sentiment, I’ve advocated for more conservatism for a long time, but CTV **is** the conservative approach and it **is** something explicit that we know the limits of. I think the notion that we shouldn’t implement simple, very contained functions because we haven’t predicted everything that could be built with them yet is a misunderstanding of how and why we should be conservative. Example: The justification to reject timelocks or multisig because no one had yet predicted the existence of lightning and how it would work would be silly. It’s literally an impossibility to know what will be built with new tools, that’s the whole point, but how they are contained and HOW they work within the transaction is the concern. And CTV is essentially little more than a hash lock, something we understand in dozens of other contexts and with a very simple and very environment limited function.

Ok, then prove to me that it can’t be abused. You can’t prove a negative so to prove it can’t be abused, you must first list all classes of ways it can be used and then prove those can’t be abused. Since you can’t list all the classes of ways it can be used, you can’t prove it can’t be abused. So therefore your statement that you know the limits of it and that it’s safe is not true. You don’t know the limits of it. If you did, you could tell me. Right? Timelocks and multisig have classes of uses beyond lightning so you’re right, it would have been silly to reject them because we didn’t know of the potential of lightning. We already knew other ways they could be used. For example, shared custody. It’s not just a hashlock, is it? If it were just a hashlock we could use pay-to-script-hash (P2SH). Think about it more. You have everything backwards. In product design, we don’t build technology first and then hunt for a problem to solve. We first identify a human centered problem to solve and then design technology to make people’s lives better. Imagine that you are a systems designer for a nuclear reactor. Would you agree to release a public API that could do a bunch of stuff that people will figure out later? No, you wouldn’t. Someone might accidentally melt down the core. Instead, you would make the most limited changes that you knew would be safe. When I look at the bitcoin core protocol. I see something more important than a nuclear reactor. The core devs are one of the most centralized and dangerous systems in the bitcoin ecosystem. Unlike individual govts, they actually do have the power to destroy the entire network. Let’s not “melt down” bitcoin’s core. Future generations are counting on us.

“Timelocks and multisig have classes of uses beyond lightning so you’re right, it would have been silly to reject them because we didn’t know of the potential of lightning. We already knew other ways they could be used. For example, shared custody.” You misunderstand my analogy here. It wasn’t that we didn’t understand it’s value because of its, it’s that one didn’t have to defend multisig as a tool by predicting everything that could be built with it to know it was safe. If that was a requirement, then we could never make any changes at all. “Imagine you are a systems designer for a nuclear reactor…” Dude I’ve done dozens of shows on this, you don’t need to argue that this is foundational, nuclear grade software, that this should be treated with utmost care, that upgrades should be extremely limited in scope and well understood. If you are making that argument then we aren’t actually on topic.

In order to make sure my “on topic” comment isn’t too vague, I’m saying that we both completely agree on this point and the argument is about *what* the conservative, save for nuclear grade options are. So to equate CTV with an open API is to misunderstand that I’m saying CTV appears not only the safe, and most conservative option while still getting the functionality we want, but that explicitly comparing it to previous soft forks, it’s *easier* to justify than a bunch of things we’ve already soft forked for. So what I’m saying is that I agree with basically your entire post. I *disagree* on where CTV falls in that risk profile.

You say it “appears to be safe”, but have put forward no justification to support that statement. You can’t say just say “trust me” to the bitcoin community. We need the “verify” part too. “it’s *easier* to justify than a bunch of things we’ve already soft forked for.” Sure, but you and I both know that’s not a real argument. Arguing that devs were more reckless in the past doesn’t justify additional reckless protocol changes. That past recklessness explains why we have the witness discount, more spam data in our timechain, and additional centralizing forces on miners. Bottom line: if you’re advocating to change the core protocol, you have an obligation to demonstrate that it’s safe and necessary. You owe the community this. And since you have a highly visible platform, you have a duty to use a higher standard of care … a higher bar, if you will.