Bad news about OP_VAULT https://twitter.com/reardencode/status/1756185478716657830
(I have not checked Brandon's work on this, but you can see that I had the intuition about it independently)
I want to remind everyone that CTV alone enables vaults https://github.com/jamesob/simple-ctv-vault
(jamesob designed OP_VAULT around the problems with these simple vaults, so that's not to say they're perfect, but I believe they are useful. In fact, I believe simple vaults gives us 90% of what we want anyway.)
Bad news about OP_VAULT https://twitter.com/reardencode/status/1756185478716657830
(I have not checked Brandon's work on this, but you can see that I had the intuition about it independently)
Why APO? CTV + CSFS allows "floating" transactions which seems to be the feature most people want from APO in the first place. APO also enables hashrate escrow.
Not sure it's very useful as described in this article but https://rubin.io/bitcoin/2022/09/14/drivechain-apo/
Lightning cannot scale to even 1 billion people without L1 improvements.
Looks like it, NIP-36. Coracle needs support 😩
Does nostr have a standard nsfw/content warning tag like the fediverse does?
Who doesn't think that?
ReardenCode is absolutely a good actor in the space and he thinks OP_CAT is ok, but his "OK" is based on "MEV is actually not as big of a problem as people think". I'm not willing to test that hypothesis on mainnet any time soon, and not without a VERY compelling reason.
Denial of service is only one problem, perverting miner incentives with MEV is THE problem imho.
More importantly, OP_CTV opens up all sorts of possibilities, with none of these concerns.
OP_CAT is a pandora's box of *potentially bad* script possibilities.
Iff we have exhausted what we can accomplish with OP_CTV and have decided we need more functionality, I *might* consider OP_CAT, but it's so incredibly out of order to propose activating it now it's insane.
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)
What paper are you referring to? The original uses descending timelocks for updates unless I'm missing something.
Regardless, a simple coinpool like tr(
That would be pretty funny
The original channel factory paper definitely doesn't. It doesn't even require CTV. What are you talking about specifically?
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.
Sorry timeout trees *are* really just for lightning, but my core point about channel opens remains the same
What attack vectors?
Did you read the rest of the thread? There are tons of benefits.
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.
Channel factories can be done with just CTV. LNHANCE includes CTV of course.