> Just noting that the "what is the ultimatum" section is still a
> standing question
I think this is outside the scope of the letter and this discussion -
different cosigners will have different ideas about what should happen
if another 6 months goes by without a serious attempt at review and
integration. We'll cross that bridge when/if we come to it.
> I don't want to do crowd estimation but it seems clear to me there is
> higher excitement for this one.
We certainly agree there. I know I'm personally more excited about this
package than just CTV. I only meant to suggest that there are many
people who would have liked to see CTV active on its own earlier.
> It clearly can be a liability if the relative utility of CTV is
> damaged by a possible future change, even non-consensus ones, some of
> which are already being deployed with non-zero miner support such as
>
https://x.com/PortlandHODL/status/1921350395424563572 .
Worth noting that Portland himself, on behalf of MARA Pool, is a signer
of the letter.
> I offered the "P2CTV" template for exactly this purpose, please
> consult the patch I wrote. There's no need to introduce more script
> execution to support it.
I assume by "more script execution" you're talking about simply allowing
the same script interpreter path that everything else uses for CTV on
legacy, as it's currently written.
Maybe others can debate about whether bumping to a new witness version
is a larger or smaller conceptual burden than just dealing with legacy.
I don't have a great sense of it. Naively it sounds workable to me, but
I still don't really agree with the premise that enabling CTV in legacy
is complicated or dangerous.
> The Delving thread is declaring that it's a game-changer for BitVM, to
> some knowledgeable people it's obviously considered a feature. If I
> understand correctly it literally changed Robin Linus' opinion on the
> proposal for CTV!
Worth noting that even after the discovery that this hack isn't a real
use for CTV, Robin still signed this letter. But I will let him speak
for himself.
> From my discussions with other BitVM implementers it certainly sounds
> practical? Forgive me for not taking your word for it.
I think we might be confused here - I'm certainly not calling BitVM
impractical, or what they were trying to do more generally. I'm just
saying that CTV might not be the appropriate tool for it, which I think
is now clear to everyone. CTV shouldn't really be blamed for this
because it was a known hack to begin with.
> A way to commit to a neighbor prevout in some way. If that's the
> capability we want, we should design for it. If it's not, we should
> mitigate it by disallowing it.
The point of this whole discussion is that scope expansion continues to
happen ad nauseam and consequently no progress is made. This can be a
separate consideration with a separate design process without harming
anything.
> I still think CTV(again in the capability sense) + CSFS are worthy of
> consideration, but this is a surefire way to sink it.