Oddbean

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.