Oddbean new post about login | logout I’m not in favor of generic expanded capabilities to the core protocol where we don’t know the limits of how they will be used. It would be better, IMHO, to pick specific use cases that the community wants and to then engineer the best, most limited change that meets that need. Vaults? Payment channels? Etc. We should design a change to do just that and only that. We need to learn our lesson with Taproot and discounted witness data. Devs didn’t realize how it would be used for spam. Devs aren’t omniscient and can’t predict all ways a change can be abused. Some of the abuses will even be indirect and attack the incentives underpinning key operations (like mining). Best to lock it down to reduce the attack surface area.
“I’m not in favor of generic expanded capabilities to the core protocol where we don’t know the limits of how they will be used.” This is exactly why CTV makes the most sense. It’s a simpler primitive than probably any soft fork we’ve had since the beginning of Bitcoin
I know, but that’s terrifying isn’t it. It’s why we ended up inadvertently centralizing mining with Taproot and making it difficult for folks like me to periodically sync the blockchain on our small TOR nodes. Secret blocksize increase after fighting to keep it small. Why not simpler still? Why not op_vault? What specific use cases are your priorities? I’m sure the community had a top one. Why can’t we just focus on it first? I’ve only heard from devs, “I think it’s safe”, which isn’t appropriate for the system that protects the world’s money. We need to be absolutely certain that it’s safe.
How is that terrifying? And how exactly have you reached the conclusion that taproot has been responsible in any way for centralizing mining? Are you saying people wouldn’t be using pools without it? Or that mining somehow wouldn’t have been financialized? I think you’ve equated cause and effect with things that have nothing to do with each other.
And how on earth do you gauge op_vault as better here? Seriously what do you know about op_vault? It’s actually more expressive than CTV as I understand it.
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.
It’s terrifying because nobody knows the limits of its use and therefore nobody can say with any certainty that it’s both (a) technically safe and (b) won’t disturb the network ecosystem. My understanding is that taproot and segwit’s witness discount encouraged and increased the volume of arbitrary data stored on chain. This expanded the market for things that use this data. More data, more junk, larger market. Thereafter private apis to miners and pools developed to front-run and insert crap in the chain. Private apis and out-of-band payments encourage mining centralization by giving unequal access to fees and disturbing the even playing field. This motivates miners to join the pool that has better access to these exclusive fees and encourages monopoly-like arrangements. https://www.coindesk.com/opinion/2024/07/09/mev-has-spread-to-bitcoin-in-subtler-forms-than-on-ethereum/ https://bitcoinmagazine.com/technical/the-witness-discount-why-some-bytes-are-cheaper-than-others
You clearly don't understand CTV
Great, I’m glad someone who does just showed up. Go ahead, tell me all the ways it can be used, and prove it’s both technically safe and also doesn’t disrupt the network ecosystem.
You lock your bitcoins to a spending script. It's as technically safe as P2SH and doesn't disrupt network ecosystem because it's just a spending conditions on coins. Can you demonstrate and prove that CLTV, CSV, P2SH are technically safe and also doesn’t disrupt the network ecosystem? If not we might have to remove them :/
Is CTV being used the wild right now? In Liquid? Somewhere else? Hard for me to trust “it’s the same as” arguments because if it were the same then we wouldn’t need it. Is there a document somewhere that provides an in depth review of the safety considerations? What is the feature that it provides that you care most about? This summarizes my lates thoughts. Important to also prove necessity. nostr:note16zakjweexcw9hjawwxllrj702mnt3k9ve69lgq5am39q77vedzksnd8n4a
I'm not advocating for CTV. I'm just pointing out that your lack of technical knowledge will hinder your ability to understand those things and participate in such conversations because all of your arguments are based on feelings, not facts. There is no "we" in this. A soft fork proposal doesn't need you if YOU can't show the proof-of-work as to why your opinion is valuable or worthy of consideration. Hence, when improvements to Bitcoin script inevitably come, you will be left screaming in the void because the stakes for you are clearly not enough to have an informed, non-biased, opinion.
You didn’t show anything. You just made claims I didn’t know what I’m talking about. Ad hominem attacks are always the fallback, aren’t they? It’s not on me to prove it’s necessary and safe. It’s on those advocating for it. And apparently that’s not you. 😂 Do you just jump into random convos and yell “you don’t know what you’re talking about!!” And then refuse to support you point when challenged? Pretty funny. 😄
I have made the case for why CTV is safe, you are just not able to understand it because of simple technical shortcomings. This is not an ad hominem, simply an observation. Do you imagine people will spoonfeed everything to you? These conversations will carry on without you and you will remain puzzled and confused when changes happen because all you rely on are your feelings.
You made no such case. You only made unsubstantiated claims that it was the same as P2SH. I just pointed out that it was a false analogy to see if you could back it up. And you didn’t. It seems you’re just parroting talking points given to you from other people. Just like that meme where the NPCs all download their latest update. Did you sit in on a talk once or twice and conclude you now know everything there is to know? I often find that folks who see the world in superficial simplicity often have never built anything of value or complexity. Those who have usually realize that many of their preconceived assumptions were wrong. By the way, what they didn’t discuss in that talk you attended: Op_ctv can be used to expand time-based trading opportunities, options, futures, DLCs. https://www.coindesk.com/layer2/2022/05/20/bip-119-unpacking-ctv-and-how-it-would-change-bitcoin/ https://bitcoinops.org/en/newsletters/2022/02/02/ Trading and marketplaces create opportunities for people to front-run transactions. https://www.coinbase.com/en-it/learn/advanced-trading/what-are-frontrunners-and-mev-when-it-comes-to-crypto-trading This creates MEV or MEVil, as some people term it. MEVil motivates miner centralization. https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/ Here’s a primer on MEV in case you forgot! https://bitcoinmagazine.com/technical/mev-monster-bitcoin Anyway my point is that it’s not clear that it’s necessary and we definitely don’t know that it’s safe. I can see that there is a potential risk. I just don’t know the severity of the risk and neither do you.
You are talking about things again which you don't understand. Understandably this makes you afraid. You cannot "see" anything. You are just feeling because you can't verify yourself.
I read you correctly, didn’t I? 😎 I look forward to your actual rebuttals when you have some.
You're literally the one parotting talking points. It's right there in your notes. You reference things you do not understand and just throw link to support your "feelings". If I were to ask you to explain any of the subjects discussed you wouldn't be able to. There is nothing to rebutt, you didn't bring up anything substantial.
Oh, my! Bless your heart. I guess you don’t know how to respond when your usual bullying stops working. The only feeling I’m getting is that cringe one where you’re watching someone in the movie embarrass themselves. And also starting to feel a bit sorry for you. I explained to you how there is a risk of MEVil. I guess you can just pretend I never said it. Everyone else can see that I did and also see that you had nothing to say. I got a nice glass of wine 🍷 here. I’m going to take a drink every time you say “feelings”. Don’t keep me waiting! 😆
You explained to me? 🤣 You sent me a "primer" I wrote 🤣 Dead
And you’re so full of yourself that you thought you “got me”. It’s how I could tell you were not a builder. You’re so funny. 😂 I just added ded and dead to my drinking game. 🍷🍷 Glad Guy is focusing on the real issues here. 👍
Even though this conversation is unproductive now and I won’t be participating anymore, I’ll just leave this here: CTV would allow us to open a million lightning channels in a single block. https://media4.giphy.com/media/l3vR6eSZ9bvU6CxkQ/giphy.gif?cid=9b38fe9123jfxpqw5emt48pqvy6n4e2lgbrs23b7jr9t271x&ep=v1_gifs_search&rid=giphy.gif&ct=g
Did you mean to post Alex’s own article on MEV or was the “in case you forgot” a joke about that?
DED
😂 of course. It was clear from his writing that he wasn’t a builder. Thought he needed to review his primer. Too funny. Look at him. Was hoping he would say feelings again so I could take another drink.
I read through most of what you linked to here and I haven’t found a single connection between MEV and CTV in any of it. In what way do you think CTV will cause this issue? None of what it does can be done *to* someone, you have to sign and place all the signature requirements into it yourself. The first article does a decent job of explaining why it’s very useful, but also makes almost no change in the security assumptions, because it’s just another type of restriction you can place on your own coins. Literally Lightning is trying to do exactly what CTV does, except in a complicated, multi step, numerous interaction way. So if the basic function of CTV is bad somehow, then so would a multisig that attempts to have rules not in the actual transaction to adhere to… ie. You and I are in a multisig and we agree that .1 belongs to you and .2 belongs to me. CTV literally just makes that simple and easy to understand, instead of complicated and needing multiple interactions and signings.
Thanks for the response. I appreciate the focus on the issues and the discussion. Will respond when I can.
Ok, could you please tell me which statements you disagree with so we can start from there: 1. Centralizing MEV is bad 2. Out of band payment to miners to enter private mempool can create centralizing MEV 3. Speculators may pay miners out of band fees if they can receive a financial advantage. 4. Trading financial instruments creates opportunities for financial advantage if you can execute your transaction quicker than others. 5. Op_CTV enables smart contracts that could be used to create and trade financial contacts, possibly even creating a Uniswap-like DEX. 6. There is a risk that op_ctv could create centralizing MEV
You can’t control out of band payments in any way whatsoever, to suggest you can is silly, imo. CTV doesn’t “enable smart contracts” in some elaborate way that isn’t already possible. Lightning is a “smart contract,” multisig is, atomic swaps are. What you describe is a completely generic idea and is 100% possible right now with all the op codes we have. CTV does not suddenly make a shitcoin trading empire possible where it wasn’t before, it literally formalizes, simplifies, and removes multiple interactions needed to do many of the same things we are doing *already.* Multisig doesn’t scale to large groups because everyone has to be present. All CTV does is make it so parties can make changes independently and without constant cooperation and synchronized signatures from every single party. So I disagree with the whole framing. It doesn’t make any sense in the context of what the tool is.
“CTV doesn’t “enable smart contracts” in some elaborate way that isn’t already possible.” Have you heard of Sapio? https://www.coindesk.com/tech/2020/07/14/this-new-coding-language-could-help-unlock-bitcoins-smart-contract-potential/ https://btctranscripts.com/vr-bitcoin/2020-07-11-jeremy-rubin-sapio-101/ https://bitcoin.stackexchange.com/questions/106850/is-there-anything-specific-to-the-design-of-the-sapio-language-that-makes-it-wel https://blog.primebit.com/2020/07/22/sapio-a-new-language-aimed-at-increasing-bitcoins-smart-contract-potential/?amp=1
Hey Guy, did you fall down the Sapio rabbit hole as I did? Pretty interesting (and disturbing) stuff! Anyway, unless I’m missing something, it seems that you were misled on CTV’s capabilities. You said: “CTV doesn’t “enable smart contracts” in some elaborate way that isn’t already possible…” Your statement is not true … straight from Jeremy Rubin himself: “When we write a program in Sapio, we are designing an arbitrary state machine that can run any program.” …and… “As such, Sapio is a very powerful framework for designing Bitcoin smart contracts […].” So CTV does provide a NEW powerful framework that allows ARBITRARY programs, which aren’t possible today. Jeremy even says at one point that you can write options contracts in Sapio. This confirms what I said about financial trading. Jeremy also says clearly that Sapio is ONLY POSSIBLE with CTV: “CTV makes all this stuff really possible and without it it is severely limited in what contexts you’d want to be able to use it. … Getting CTV adopted is really instrumental to making this vision that I showed you actually work.” So, to recap: You’ve said repeatedly that CTV was only providing capabilities that we have already. You said that CTV doesn’t provide “elaborate” new smart contract capabilities. You now have strong evidence that both of these statements are not true. Do you understand now why my earlier framing was accurate? If you’re still fuzzy on anything please let me know. Hoping you also understand better why I challenge these attempts to quickly change bitcoin’s core protocol. Of course I would love to have channel factories capable of opening a million lightning channels at once. But not if there is any risk to bitcoin. The problem is that none of us really know what OP_CTV can do. It seems this discussion is a perfect case in point. You’re super smart, incredibly well read, spending most of your time in this space, but still under the belief that OP_CTV just provides better hashing, stuff we already have. Nobody understands all the ways it can be abused, so nobody really understands what the risk to bitcoin really is. You think we need channel factories? Great! The dev community should explore how to add that without any “side effects”. We absolutely need vaults. Hopefully they can figure out how to get that done without side effects too. But adding arbitrary programs to the core protocol which could harm decentralization? No freaking way. We’ve seen that horror story play out on crypto blockchains.
I already left this convo and don’t have time to read all that, I have been well aware of Sapir for years and I’m guessing you’ve never heard of BitVM if you think this is something new.
Sapio runs logic on-chain but BitVM is currently designed to run logic off-chain. You can’t equate them. Big difference in terms of risk to centralizing MEV, don’t you think? It will be interesting to see how BitVM develops though. You’re not going to respond? Once I brought receipts and then you suddenly “didn’t have the time”? Disappointed. I thought we cared about what’s best for bitcoin rather than our established positions.
“You’re not going to respond? Once I brought receipts and then you suddenly “didn’t have the time”? Disappointed. I thought we cared about what’s best for bitcoin rather than our established positions.” I was literally just trying to find the time because I am insanely busy and also out of town at the moment, but you beating your chest like you are the only one who cares about anything and this sort of attitude is what makes me not want to. If you want me to respond this isn’t how to do it. And no, Sapio doesn’t change anything, as I said I knew about it and I’m pretty sure I did an episode on it a couple years back.
You’ll recall that when I was busy, i politely thanked you for your message and let you know that I would reply when I could. Perhaps you forgot saying “I already left this convo and don’t have time to read all that…” But you always intended to reply? Ok, sure. Repeating “Sapio doesn’t change anything” is weak sauce — baseless contradiction, no logic, no evidence, just nothing. I’ve quoted the author of OP_CTV extensively and he clearly contradicts you. I was hoping you would respond with something coherent so I might be able to learn, if I was missing something.
“Smart contract” is a buzzword. Lightning and multisig can do what you explain above. It’s just more annoying and requires more interactions. Are we getting rid of those things because of “smart contracts”? CTV is not a “framework”, Sapio is. It’s a coding language to work with bitcoin script, CTV is not the problem here and I also think you misunderstand MEV on top of this. There are already options contracts in Bitcoin, it’s already financialized. Also something that you can’t stop. There have been futures contracts for years. It’s completely impossible to stop practically everything you listed and maybe I’m wrong, but you don’t seem to understand what the *actual* problems with those things are, rather than thinking there’s some concrete line where it does/doesn’t exist and thinking that CTV leaps over it.
I’ll give an example to look into if you care: Lightning pool can execute any arbitrary code to enforce ownership of bitcoin. Has been able to for a couple of years. It simply uses the Lightning punishment system to enforce ownership. CTV only makes it so you can pre-sign the exits and do it non-interactively… as I explained at the very beginning.
Thank you for the response! I can see our conversation is misaligned. Might be helpful to clarify my position. I’m not pushing back on particular functionality, per se. I’m only pushing back on how particular functionality interacts with the base chain — if that interaction might create centralizing incentives. For example, I don’t reject smart contracts, arbitrary code execution, or the like, if done via multisig, lightning pools, or even BitVM (as I understand it today). I push back when it is done in a way that could harm bitcoin decentralization (eg OP_CTV). What’s the difference? On-chain vs off-chain logic. CTV’s logic is on-chain so I’m concerned about CTV creating centralizing MEV and therefore potentially creating incentives that promote miner centralization. Let’s imagine that there was a trading marketplace on bitcoin where speculators were buying and selling securities, like how Uniswap enables trading on Ethereum. If bids, offers, and pending transactions were visible and transactable on-chain, there would be an incentive for traders to bribe miners to help them jump the queue to transact before other traders. These bribes would flow as out-of-band payments through private APIs to the largest miners, creating an advantage for larger miners (hence promoting centralization). There seems to be much less risk if the bids, offers, and pending transactions are off-chain and where the chain is only used for final settlement. For example, I don’t see any risk of people trading stocks on Nasdaq and settling with bitcoin. That’s just using bitcoin as money. No problems there! I DO see a big risk if people are trading stocks on a “bitcoin Uniswap” if there is any possibility that people may want to pay miners privately to jump the queue. This is why lightning pools and BitVM don’t concern me — the logic is off-chain and the chain is only used for final settlement. This is why I perceive a difference with CTV / Sapio. Everything seems to be on-chain. If someone could use it to create something like Uniswap then it poses a centralization risk to miners. You can also think about this another way, specifically that types of transactions classified as safe or unsafe. For example, the safest transactions are using the chain for final settlement, and are publicly broadcast so that no miner can have an advantage. Unsafe transactions are those using the chain for some other purpose where there is some incentive to connect privately to a large miner. (That’s why inscriptions were so bad. Promoting node centralization by filling the chain with spam, while promoting miner centralization through private transaction APIs. Double whammy!) Eg, MARA’s Slipstream API: https://x.com/JStefanop1/status/1760764664651133162 Jeremy was clear that OP_CTV could be used for anything. He even demo’ed playing tic tac toe on chain. This is why I put CTV in the unsafe category. I’m also not trying to quantify the risk. I’m in no position to assess whether it’s likely or not that someone will abuse CTV, CAT, etc, or how they might try. (And, nobody can really know.) My position is that these changes to the protocol should be rejected solely based on their architecture and potential for abuse.
