Does anyone following me have a technical/incentives concern with CTV?
Discussion
I do.
What can we do with it that will make it possible to scale Bitcoin to billions of users?
CTV enables coinpools, giant channel factories, Ark, and timeout trees. Each of these offer 10x-1000x scalability improvements (with different tradeoffs). The good news is we don't need to handle billions yet, but CTV gets us close (or maybe over!) the first Billion.
Coinpools are like multisig between multiple people, right? What is the scalability you get from that?
Channel factories can't be done with CTV. It requires LNHANCE or APO, right?
Channel factories can be done with just CTV. LNHANCE includes CTV of course.
This is wrong. You cannot do it with just CTV.
The original channel factory paper definitely doesn't. It doesn't even require CTV. What are you talking about specifically?
Of course, it requires NOINPUT, or APO, not CTV.
What paper are you referring to? The original uses descending timelocks for updates unless I'm missing something.
Regardless, a simple coinpool like tr(
I see. I am talking about multiparty channels, which are often referred to as channel factories, but it's an ambiguous name.
Timeout Trees are just a way to open more Lightning channels, right? But that isn't the problem with Lightning. Force-closes are.
Have you seen nostr:npub169n9eaf0t20j0nefwqlqtnqcpsym22k2nw6e3tevtrrru4et7wrsh5w47v and nostr:npub1l8wk5a39qcnqkw9z60jmgepp8shy073cwapfl60wvrs8rgc6qltsq66m2c?
Timeout trees can be used for lightning channels but it's not really their only use.
Lightning's biggest problem actually IS channel opens right now, it would take ~5.5 years to open 1 billion lightning channels right now. Whereas you could (in theory, but there are practical limits much lower) open 1 billion lightning channels in one transaction with CTV.
*Then* the problem becomes uncooperative closes (force closes and attempted thefts). If you have a billion people competing for block space to handle closes, that could get messy too.
But if we can use CTV to increase channel open capacity, and we can limit the need for uncooperative closes, then overall capacity dramatically increases.
Sorry timeout trees *are* really just for lightning, but my core point about channel opens remains the same
Closes are already a problem today. It will only increase if you start to open more channels with TT.
Currently it's cheap to open a channel, yet it costs a lot to force-close, and it happens all the time. CTV does nothing to help with that, nor does any other opcode proposal.
They are *a* problem but they are not *the* problem if we can't open the channels to begin with. That's like saying the problem with a plane that can't fly is that it can't land.
Closures aren't remotely driving block congestion anyway.
I feel like I haven't heard a good argument against CTV other than "unintended consequences" (always a valid concern imo)
I totally agree about unintended consequences, but CTV is so simple I'm pretty confident there's nothing to worry about. It's the simplest possible covenant I'm aware of.
Right, and for that reason I'm most open to CTV discussion. There's been a lot of "the devs/miners love CAT and we should now go with that" the past couple days on twitter and it's unsettling. I wonder if CTV ends up being a compromise between devs and skeptical node runners in the future.
Yeah I'm also unnerved by that. I can be convinced OP_CAT is safe but trying to activate it before or soon after the incredibly safe CTV seems insane. CTV does so much for us without opening up pandora's box...
The only thing I'm really aware of is the "thundering herd" where you have, for instance, millions of people who have vTXOs who want to get on chain all at once. I think I'm comfortable that it's at least no worse than the status quo where we can't even attempt to serve that many people, but maybe it ends up turning into a "trap" that reks a bunch of people?
Haven't heard about this but how would that be any different from millions of people trying to use the base chain all at once? Cuz that would obviously take a good while to process.
It's basically the same, except imagine the difference for users between "I couldn't buy in to Bitcoin because it was congested" and "I bought into Bitcoin but now it's completely stuck because it's congested".
Plus, with L2s like lightning, you need to be able to get your "corrective" transaction on chain within a certain time period, otherwise your channel partner could steal. (You need to get your Penalty transaction in ln-penalty, or update transaction in ln-symmetry confirmed)
I'm pretty sure at least *specifically* with channel factories and timeout trees + lightning, it's not much of a concern, since your channel partner's attempted theft would mean unrolling part of the tree anyway, they actually shoulder most of the fee burden in that scenario, so they have incentive to continue behaving. (Don't take my word on this, I've only half thought it through)
There might be other constructions that create a greater risk though.
what is it?
It brings no discernible benefit but allows for more attack vectors
What attack vectors?
Did you read the rest of the thread? There are tons of benefits.
Taproot has enabled a few negative things that no one had previously realised. What negative things are made possible by CTV? Why can't it be tested on Litecoin or any other chain first?
If it helps you to think about it, you can emulate CTV (poorly, with caveats) with presigned transactions that have always been possible.
It's fair enough to be concerned about unknown-unknowns but I'm asking for specifics in this thread. (I'm pretty convinced it's safe after a couple years of thinking about it but that's just my opinion)
I'd rather hear the technical downsides are, like centralizing templates.