From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Date: Mon, 10 Mar 2025 18:06:40 -0700 (PDT) [thread overview]
Message-ID: <5610731e-b4a3-448d-bf4b-508739d51198n@googlegroups.com> (raw)
In-Reply-To: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 9706 bytes --]
Hi James,
> As with everything in bitcoin, the chain is insulated from stupidity like
that
> by fees, the UTXO model, and block cadence, so what's the problem?
See my novel answer to AJ that by extending bitcoin script, I think you
might *actually*
diluting the UTXO model as you can now on cross-inspect the status of an
outpoint.
This might amplify tx-withhold style risk for bitcoin contracting
protocols, e.g vaults.
> Probably worth noting that CSFS and many advanced introspection opcodes
(which allow synthesizing
> CTV) have been live for almost *four years now* on Liquid
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality).
Live != Deployed use-cases built on top of those advanced introspection
opcodes.
I've not verified this by myself, though from what is available from public
data
L-BTC is <= to LN today in terms of locked coins. In terms of
decentralization,
a federated side-chain is not even like a network of payment channels, where
everyone can join by confirming a 2-of-2 in the chain. So have skilled dev
really
try do "wrong things" with L-BTC and all those shiny introspection opcodes
? I'm
not sure, and please accept my skepticism here.
> Sorry to tell you, but given that changing consensus requires soliciting
buy-in from a
> wide variety of people across the Bitcoin ecosystem with varying levels
of technical
> ability, it is inherently a political process.
No -- Apologies to tell you that science / engineering != politics.
Somehow, if one has taste and familiarity with all postmodernism sociology,
there is well one domain where it completely failed to demonstrate that
things
are following a "political process", this is indeed the domain of science.
In
science, mathematical or physical truth always prevails, no matter what.
Don't get me wrong -- This doesn't mean I cannot share the opinion that
current
consensus changes process is a complete conoundrum. Sadly it might have
devolved
in the view of numerous segments of the Bitcoin ecosystem that what matters
w.r.t
consensus build-up is who is sitting on a bunch of surreanous github
repository
permissions, and not necessarily if the consensus change is benefitful in an
objective fashion for bitcoin, not even if such _consensus change_ might be
required for the long-term flourishing of bitcoin (at least fixing the
technical
debt).
There is difference in saying what makes you socially popular to be vetted
with
empty github permissions and let you vegetate on them by a weak social
consensus
and there is a difference in saying unpopular truth to nurture real changes
on
the long-term. I won't open the conversation more on that subject.
Now, back to the more technical analysis of covenant, personally my position
is still the same than it was discussed on Bitcoin Core #28550. The
communication
tone was rude, for sure, though I still share the same belief we shouldn't
be
careful in designing contracting primitives and be completely $YOLO if said
primitives works well for a second-layer.
On concerning CheckTemplateVerify itself, which is itself simpler than any
other proposed soft-forks due to the non-malleable templating, as I said 18
months ago I'm still open in my free time to review/test a CTV-based vault
(https://github.com/jamesob/simple-ctv-vault), the same way I did for
Eltoo-based
LN channels in the past. This is one thing to come with a proof-of-concept
working on a single workstation, this is another thing to have tested it
under real operational guidelines, where dynamic fees and keys ceremonies
have to be deal with.
I don't think CTV is altering the UTXO model significantly, though pleasure
to be proven wrong here. On the other hand CTV is bringing this idea of
immutability in a chain of transactions, that we cannot do currently with
sigs-based covenant. That immutability in theory has consequential value
for anyone building cold wallet or vault, that is clear as once the funding
utxo is confirmed, the UTXO signing keys leaks are void.
Now, I might be the last guy in the ecosystem to think that CTV is not
the promised silver-bullet by its author all over the world to design
and deploy vaults. Fine.
> Beyond that, "Overton window" is an appropriate device in the sense that
roasbeef
> is using it because the more substantial a proposed change is, the more
time is
> needed by the technical ecosystem to digest it, both in terms of tooling
and safety
> analysis. Introducing an entirely new script interpreter on the basis of
a Lisp (or
> combinator calculus, or whatever Simplicity's claim is) is indeed far
outside of
> that "Overton" window - much farther than tacking on what is essentially
just a
> new SIGHASH mode to the existing interpreter.
I do not wish to be overly pessimitic, though I think whatever
"just-drop-a-new
script-interpreter" approach is just the wrong design approach, if we do
not go
to fix first all the dynamic fees issues grieving all the contracting
protocols
and bitcoin second-layers.
Side-note: if you're used with playing with your compiler to target exotic
ISAs, one could build the equivalent for any Lisp interpreter where there is
an IR and in function of the target you compile to current supported bitcoin
opcodes, disabling interpreter syntax that are not (currently) supported or
that cannot be translated. I think this would be already a formal
verification
gain for any smart-contract toolchain using it, even if it's a subset.
> Let's not be petty here - it's clear he's talking about LoC within the
script
>interpreter, which is a different context than the codebase as a whole.
Within
> the context of the interpreter, LoC is indeed a decent heuristic for
marginal risk. Of course, nobody's saying it's perfect.
I agree that LoC is a decent heuristic for marginal risk.
Best,
Antoine
OTS hash: 7f00760799b4defd9fe551673a7926c01704274e522d44f3dc8e701b320243de
Le samedi 8 mars 2025 à 16:39:34 UTC, James O'Beirne a écrit :
> On Friday, March 7, 2025 at 4:26:36 PM UTC-5 Anthony Towns wrote:
>
> If you instead did not delete the CSFS private key would allow you to
> swap in another hash H or signature S in future. That would perhaps
> allow designing an unbounded state machine where a master key can add
> new states in future.
>
>
> I'm not sure what your point here is - that we can do stupid things with
> CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded
> state machine" by sending myself the same UTXO back and forth indefinitely
> with CHECKSIG.
>
> As with everything in bitcoin, the chain is insulated from stupidity like
> that by fees, the UTXO model, and block cadence, so what's the problem?
>
>
> https://github.com/ElementsProject/elements/pull/1427 suggests
> Simplicity's potentially going live on Liquid any day now.
>
>
> Probably worth noting that CSFS and many advanced introspection opcodes
> (which allow synthesizing CTV) have been live for almost *four years now*
> on Liquid (
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality
> ).
>
>
> The concept of an "Overton window" is a political one, used for when
> there has been successful political pressure to exclude some subjects
> from discussion for reasons other than their underlying merits. That's
> not a good idea if you want to maintain high quality, and it's probably
> not compatible at all with a project that aims to be decentralised in
> any meaningful way.
>
>
> Sorry to tell you, but given that changing consensus requires soliciting
> buy-in from a wide variety of people across the Bitcoin ecosystem with
> varying levels of technical ability, it is inherently a political process.
>
> Beyond that, "Overton window" is an appropriate device in the sense that
> roasbeef is using it because the more substantial a proposed change is, the
> more time is needed by the technical ecosystem to digest it, both in terms
> of tooling and safety analysis. Introducing an entirely new script
> interpreter on the basis of a Lisp (or combinator calculus, or whatever
> Simplicity's claim is) is indeed far outside of that "Overton" window -
> much farther than tacking on what is essentially just a new SIGHASH mode to
> the existing interpreter.
>
>
> Certainly a small change (though LoC is a bad measure of that -- how
> many LoC does it take to drop the 21M limit, or to drop the subsidy from
> 3.125 BTC to 0 BTC?) is better than a large change all else being equal;
> but all else isn't equal: different changes enable different feature
> sets. The question you should be asking is whether we're getting useful
> feature sets from the small changes being proposed.
>
>
> Let's not be petty here - it's clear he's talking about LoC within the
> script interpreter, which is a different context than the codebase as a
> whole. Within the context of the interpreter, LoC is indeed a decent
> heuristic for marginal risk. Of course, nobody's saying it's perfect.
>
> James
>
--
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/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11996 bytes --]
next prev parent reply other threads:[~2025-03-17 13:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 0:01 Anthony Towns
2025-03-05 6:14 ` Olaoluwa Osuntokun
2025-03-05 16:14 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-06 17:17 ` Greg Sanders
2025-03-06 18:36 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-06 21:26 ` Antoine Riard
2025-03-07 21:36 ` Anthony Towns
2025-03-07 21:01 ` Anthony Towns
2025-03-08 15:55 ` James O'Beirne
2025-03-11 1:06 ` Antoine Riard [this message]
2025-03-05 17:53 ` 'moonsettler' via Bitcoin Development Mailing List
2025-03-05 22:46 ` Antoine Riard
2025-03-07 21:16 ` Anthony Towns
2025-03-10 22:36 ` Antoine Riard
2025-03-10 5:14 ` Nadav Ivgi
2025-03-12 3:48 ` Anthony Towns
2025-03-12 10:02 ` Nadav Ivgi
2025-03-12 16:15 ` Nadav Ivgi
2025-03-14 3:20 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5610731e-b4a3-448d-bf4b-508739d51198n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox