techfeudalist on Nostr: Yeah, I’ve done a lot of research and am a developer. I’ve written a lot of ...

Yeah, I’ve done a lot of research and am a developer.

I’ve written a lot of research on the topic already. You can start here and review my threads.

quoting note1w0l…rvd9

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.

I’m happy to debate anything.

Liquid is an L2 because it operates as a secondary network on top of bitcoin, inheriting its security guarantees. Both lightning and liquid operate through two-way pegs from bitcoin. Sidechains can be secondary layers too, ya know.

We don’t need the ability to open a million lightning channels right now. Maybe people will want to use self-custodial lightning in the future, but they clearly don’t right now. You can ask the Mutiny devs if you’re unclear why.

quoting note1wr4…gyku

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:

note1ejc…cj2p

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.