You could probably get many Haitians (and Americans) to eat a cat on video for under $1000. 
The new OpenAI 4o1 preview seems much improved for coding.
I don’t see how that thread debunks because it assumes a choice between one or the other. Why not both? Wouldn’t a rational actor attempt the cheaper private API transaction first? And if it didn’t complete in time, to then expand distribution, first to other private APIs and then later to public broadcast?
Also moonsettler’s analysis in the thread seems handwavy. “There is no guarantee that they would find a block in the timeframe you need it.”
Isn’t that use case dependent? What % of use cases are infeasible? And if the transaction is sent to the two biggest miners, now what % of use cases are infeasible?
Once a potential risk is identified, then proponents opine that the risk could be small. But how do they know?
I don’t know the magnitude of the risk either. How could I? To say conclusively, we would need a crystal ball to know all the ways the feature could be used or abused at any time in the future, even 100 years from now. If we get it wrong, we can’t just say “Oops!” and easily remove it.
Responses to your points:
➡️ People can trade financial contracts with DLCs.
I’m not concerned with P2P trading, with primary origination on-chain, or with secondary trading off-chain that happens independently of miners. I think the issue is secondary trading of options directly on chain.
➡️ What specific centralizing MEV is enabled by CTV?
Right now, I’m concerned about the potential for time-based and cost-based private transactions that could create centralizing MEV.
➡️ No AMM can be built with CTV / Sapio.
I think you would need to show that all AMMs must have a fundamental marketplace or contractual state that cannot be modeled by Sapio. It seems to me that if there is any possibility that there could be any secondary on-chain trading, then we can’t rule out the potential for time-based centralizing MEV through arbitrage, front-running, etc.
➡️ MEV already exists elsewhere.
Sure, but we don’t want to open the door to other abuses and make it worse. Protocol changes should do no harm.
➡️ It’s difficult to extract MEV currently.
This is a statement of what is happening today given current use cases and bitcoin’s current size and maturity. Opportunities for MEVil will change over time as new abuses develop and as bitcoin grows. Once the door is open, we can’t close it.
I've started a new Geyser fund for Libre Relay: https://geyser.fund/project/librerelay
I've ported Libre Relay to Bitcoin Core's new v28.0rc1 release, and I'm trying out Geyser to see if I can get my time paid for. I'll release the code if I do.
There are a lot of pesky security protections in core. Glad someone is focused on removing them. 👍
What am I missing?
I agree with your note.
Yes, CTV does make it worse. Peter focused on the difference in *cost* but he didn’t discuss the difference in *time*. Transactions through a private OOB API could be much faster than propagating a regular transaction through the entire network.
CTV opens up the potential to create financial marketplaces on Bitcoin. With CTV, you can run arbitrary code on chain, with the only exception being that you need to know in advance all the ways the program can return. You can use this to trade options, make atomic swaps, etc.
To learn more:
It seems that most bitcoiners have the impression that CTV is just “covenants” to make channel factories and payments better. I believe this is misleading. CTV is actually an advanced NEW smart contract platform that RUNS ON CHAIN.
Are you familiar with Uniswap and all the MEV opportunities created by financial trading and arbitrage?
So, being able to trade quickly to front-run pending transactions can be profitable. CTV exacerbates the problem because it conducts everything on chain where it is visible because of the blockchain’s transparency. This trading wouldn’t be risk if it were conducted say on Liquid and later settled on bitcoin.
That article above ends with this quote:
“A fair conclusion to the preceding technobabble is this: The more complicated the thing you’re trying to do is, the more likely MEV will occur (just like in regular ol’ finance).”
I think this is true. If we add arbitrary code execution ON CHAIN, we are in uncharted waters.
nostr:note1vgvhwjn6ewsr7z4cq0qc4j4fpz0aqrc66u5xt7r7fat35p5s09uqlvggjv
nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm specifically said in his post:
"The current CTV proposal in BIP-119 has only one hashing mode, known as the DefaultCheckTemplateVerifyHash, which essentially commits to every aspect of the spending transaction in the template hash. From a practical point of view this means that in many circumstances the only available mechanism for fee payment will be CPFP. As mentioned above, this is a potential problem due to it making out-of-band fee payment a non-trivial cost savings in cases where the CTV-using transactions are small."
So he's specifically saying that out-of-band fee payment could be cost savings for small CTV-using transactions.
IMO, you could make the exact same argument for lightning force closures. Even though lightning will move to anchor outputs, which means 0 fee force closures, that will be CPFP'd thanks to "package relay". Those small transactions could have cost savings with out-of-band fee payments.
But obviously, no one is pushing against package relay. For most small transactions, out-of-band fee payments would be a small cost savings.
In fact, this statement could technically be true for any pre-signed transaction scheme. Does that mean we should never have any pre-signed transaction schemes? Hardly.
So, since this issue already exists in Bitcoin and is only relevant to very small transactions, and since CTV can actually decentralize mining even more (https://utxos.org/uses/miningpools/), I'd argue these issues are known, and the concerns with not having CTV are actually a great risk to Bitcoin. Not having covenants, IMO, is a huge risk to Bitcoin custody centralization and people choosing not to self-custody.
CAT is an entirely different beast, and I agree that the risks are much more unknown.
https://petertodd.org/2024/covenant-dependent-layer-2-review
Thanks for the response!
Yes, it’s not clearly worded, but I think he’s saying that for small CTV transactions, it might be more expensive to use CPFP than to make a private OOB payment to a miner. And he calls this a potential problem.
I think he’s glossing over a lot, but before we get to that, let’s do a quick sync on terminology so we can make sure we’re on the same page.
Payments to miners can be public or private. A public payment is broadcast to the entire miner network and the winning miner receives it. These public payments are perfectly fine and have no risk. The key is that every miner has access and competes on hashrate as per the incentives of the mining network.
Your example of a forced lightning closure is a good example of a public payment. CPFP is another. I have no issues with publicly broadcasted presigned transactions. I agree that these aren’t risky. (And package relay is awesome too.)
Private OOB payments are the risky ones. These are payments made via private APIs to a large miner to submit or to reprioritize a transaction.
Eg, MARA’s Slipstream API:
https://x.com/JStefanop1/status/1760764664651133162
These private OOB payments create centralizing incentives. The larger miners make disproportionately more revenue than smaller miners. The greater the private revenue opportunities, the fewer the number of miners we can expect to have.
Do you agree with the distinction between public and private payments to miners?
We can chat about that more, or we can chat about why CTV has the potential to create those risky private OOB payments.
A long article but I wanted to emphasize an important point.
Ethereum became trapped and centralized because of the success of stablecoins on their network. The bankers behind the stablecoins were able to dictate the software of the chain.
This is another example of unanticipated consequences. Did those devs realize that tokens on ethereum might end up controlling the network?
Even when a protocol change is technically safe, it can still have side effects that can undermine the decentralization of the network. nostr:note1ulyal0skyneukusrj9kzhsyatx0l7lr8qu6jcdhq6ehezcpwz7cqj4lzqj
IMHO, the greatest product advice ever given.
Compare what he said with Apple today. The Vision Pro was a disaster because they no longer follow Steve’s product design framework.
When you watch the launch video for the Vision Pro, you can see they weren’t sure what it would be used for. They made the old mistake: marketing technology instead of focusing on real human needs. Maybe Apple’s old institutional knowledge has been lost by now.
In Monday’s product announcement, they practically hid the Vision Pro. Sad. All that work for nothing.
New suggested slogan:
“Designed by committee in California” nostr:note1gvc46j0telzsmqrm3eldvfcpqtrh8hdewnf09sny4hrtfk7zen2sv8sgnx
Three NY buildings, two planes.
I know! Pretty soon will never know.
What do you think? In the future, when bots and people are indistinguishable, will we still use nostr-type networks?
Maybe someone will build an app game where you have you build your own social media network and you build up your following through memes and witty remarks to become like Elon Musk on X. Millions of “followers”. You can chat with any of the personalities. You get fake demands from virtual countries and you have to respond. The Elon sim game with lots of drama. In the game, you can be anyone you want to be. 🤔
😂 podcast? Which one of Peter’s or Matt’s written articles is the podcast?
Not sure what “podcast” you heard there, but did those voices in your head tell you that Peter and Matt were wrong?
You know, telling me “the voices said so”, would actually be more evidence and logic than what you presented!
I learned a lot here. Peter, Matt and everyone are wrong. But only you know why but you can’t explain. But the answer is somewhere on your website but you’re too busy to tell me what it is. 😂😂
I’m sad that you became so busy when you couldn’t articulate an answer. I was hoping you were going to try and explain why Peter and Matt were wrong. Oh well. 🤷♂️
Too many people are willing to risk the entire network because they are essentially impatient and have a need to be “innovative”.
They imagine all the future problems we might face, and get excited to “solve” them by changing the core protocol, ignoring the inherent risks.
We don’t get do-overs. We have one opportunity to have bitcoin and replace central banks. We can’t mess it up.
Seems like good evidence for another conspiracy theory. The US and the UK may have interfered in the Ukrainian peace deal to provoke a Russian invasion.
I suspect it wont be long until there is a fresh npub with each post using an LLM so that there is no text pattern. It will just look like a new user.
Eventually each npub will have a full LLM created profile too, complete with an image icon. We won’t be able to mute or block, except to block new users.
The attacker might also fill up people’s DMs with useless messages to make DMs unusable too.
It does cost something for the attacker to maintain the attack, but they can reduce their costs by focusing it on large accounts and new users. If the attacker just focuses on new users, and makes the apps unusable for them, we might not even realize the severity of what’s going on.
Anyway, this is what I could do, and I’m assuming the attacker is more skilled than me.
We need to start putting in these defenses ahead of time, thinking like the attackers, so that we aren’t surprised by the ongoing escalations.
😂 so funny! You’re still pretending that I didn’t send you direct quotes from Peter and Matt! We all know why you ignore them. You’re not capable of responding. You were so overconfident and now you’re just embarrassed.
Here, I’ll send them again so everyone following you can see you’re pretending not to see them.
Here is Peter admitting that both CAT and CTV add risks. He 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.”
The risk that Peter identified for CTV is “encouraging out of band fee payments”.
https://petertodd.org/2024/covenant-dependent-layer-2-review
Here’s Matt Corallo explaining why these can motivate miner centralization:
https://x.com/TheBlueMatt/status/1780558009841643833
Matt argues that these payments to miners are a risk because they encourage centralization:
“More recently, out of band payments to miners have become popular again, allowing individuals to pay large pools for the inclusion of their transaction(s) using payments outside of the normal bitcoin transaction fee. This can create substantial MEVil [centralization MEV risk] […]”
There you go! You can keep ignoring them but we all know that I sent them and you couldn’t respond.
🫳 🎤
I presented TWO quotes from notable developers that contradict you and you replied with no evidence, no logic, nothing. There’s ELI5 and ALY5 - argue like you’re five.
You can’t just stomp your feet and say “No it doesn’t!”
Podcasts? Everyone can see that you just ignored the direct quotes. You just completely pretended you didn’t see them! 😂
You’re in disbelief because you thought I was misinformed and yet you found yourself unable to respond to DIRECT quotes from notable developers. I can tell that you still don’t understand what they said.
You said:
“Out of band payments are essentially no different then payments in LN channels which themselves are just unpublished bitcoin transactions and thus present little to no risk.“
This is why I can tell you don’t get it yet. The problem is not HOW they’re paying the miners. It’s WHY they’re paying them.
I can tell you want to learn but are very confused right now. My advice is to focus first on Matt’s article. Why does he say that private out of band payments to miners create centralization risk?
Once you understand that, then dig into why Peter admitted that CAT and CTV can encourage these private out-of-band payments.
BTW, to understand why Peter admitted the risk, you must first understand the difference between ON-CHAIN logic and OFF-CHAIN logic.
Covenants and arbitrary code execution in systems like Liquid, etc are OFF chain and don’t create centralizing MEV (“MEVil”).
With CAT and CTV, the logic is ON chain which why they can create centralizing MEV.
**That’s why Peter admitted the risk.** He knows the difference between on-chain and off-chain logic and you don’t (yet).
So again, you need to understand why Peter and Matt said what they did, and why that contradicts your original assumption.
If you get stuck or want to discuss, just let me know! I realize that this topic is nuanced and deeper into the weeds than most people decide to go.
Carbs + oxidized seed oils
nostr:note15faajfnrwdtw6d59wezzj7w530zcqv7lyvxj7u4xah7xktwyagkst20f4y