Re: [bitcoindev] CTV + CSFS: a letter

[Anthony Towns <aj@erisian.com.au>]

On Tue, Jun 10, 2025 at 06:19:59AM -0700, Greg Sanders wrote:
> Note that I'm not totally convinced by this argument in either direction.
> Once we have TXHASH, there's really no reason to not have CAT (that's very
> small too!), maybe big num math, perhaps direct introspection. Maybe
> bllish, simplicity, or GSR? The community would have to agree on a stopping
> point, and that seems like it could be difficult to do in a
> short-in-year-terms timeline.

I think the easy way to do this is to expect both an implementation of the
features in question, and an interesting MVP/demo of how those features
can be used in practice. You then draw the line between a collection of
features that's implemented and has useful demos, versus ones that aren't
implemented or don't yet have interesting demos. If features are ready
roughly simultaneously but are largely unrelated (ie, all the interesting
demos use one set or the other but not both), then do them in parallel.

From my perspective, the main reasons that approach has not been helpful
with CTV is because:

  (a) CTV advocacy has come packaged with a "recursive covenants are
      evil, we must design to prevent them" argument, which has served
      as opposition to just about every approach other than CTV (eg,
      resulting in people doing design work on PAIRCOMMIT versus just
      using CAT)

  (b) there has been huge resistance to the idea of implementing demos
      of useful things on top of proposed features when that's brought up
      as something people might expect to see prior to feature activation

Maybe (hopefully!) that's changing with the recent PR to bip 119 [0]
and the efforts at actually building Ark with CTV; if so, I think it's an
easy and fairly objective way of figuring out when to release a feature
set versus continuing to expand it.

[0] https://github.com/bitcoin/bips/pull/1792

As I've said elsewhere, I believe the combination of "TXHASH",CSFS,CAT
would be fairly pleasant for an eltoo/ln-symmetry design/implementation
(where "TXHASH" could just mean "PUSH_TEMPLATE_HASH", rather than
necessarily being programmable tx introspection).

I believe it would be possible to build interesting prototypes for:

 - eltoo/ln-symmetry/penalty-free-channels
 - daric/fixed-penalty-channels
 - ark
 - ptlcs (via CSFS)
 - john laws' channel factories
 - lightning over ark?
 - more blockspace-efficient bitvm intepreters? (via CAT?)

If there were an open letter signed by 50 developers (or funders)
committing to prototyping half a dozen different projects using proposed
new features, and giving an understandable reports on how well (or not)
the features end up working, that would be a lot more inspiring than the
current approach that's hard to interpret as anything other than "hey,
here's a bunch of people who will harass you on twitter and insult you
on podcasts until they get what they want".

(Personally, while I think vaults are interesting, I don't think
there are interesting vault behaviours that you can implement with the
collection of opcodes that are currently being advocated for activation;
jamesob's simple-ctv-vault and the cat-based purrfect_vault included,
so I'm not listing that here. Personally, I find it hard to understand
what the purrfect_vault stuff is actually doing, hence the part about
also having an "understandable report"...)

Cheers,
aj

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEu8CqGH0lX5cBRD%40erisian.com.au.