Re: [bitcoindev] "Recursive covenant" with CTV and CSFS

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 20953 bytes --]

Hi all,

> After that, one can build a script: 
<proof-of-target-UTXO-mining=commitment_tx"
> OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY> 
<recursive_bounty_sig |
> SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker 
can
> make the funding UTXO amount available as a "anyone-can-spend" and force 
a re-
> commitment to the same tx-withholding script.

Correcting myself, after more thinking I believe to get a non-forgeable 
"proof-of
-target-UTXO-mining" there should be a merkle branch proof of the txid back 
to
the mined block. Otherwise, any participant in the target UTXO / 
transaction (e.g
a LN channel) can confirm the target transaction to execute the contracting 
protocol
according to its semantics _and_ generate the "proof-of-target-UTXO-mining" 
to
claim the "anyone-can-spend" bribing output.

So to do a merkle branch proof, script would have to be of the rough form 
e.g:
< <leaf_node_ab> <OP_SHA256> <OP_CAT> <leaf_node_cd> <OP_SHA256> <OP_CAT>, 
or
any equivalent opcode primitive allowing to get concatenation in the script.

For the design of a TxWithhold, all that you wish is a proof-of-existence 
of a
block B + transaction T (in the mathematical sense). That way if a timelock 
is
reached after X blocks, and no proof-of-existence as been brought until 
then,
this logically implies that B + T do not exist. Or at least have not been 
published,
which for the purpose of the chain being the publication space and 
anti-double-spend
oracle of UTXO spends is the same.

I don't believe with OP_CHECKSIGFROMSTACK alone you can build such 
proof-of-target-UTXO
-mining, though I'm not sure of such statement. All cov primitives 
proposals are coming
without formal analysis of the limits of the expressivity extensions, there 
has been
progress since OP_EVAL, though it's always tooling on a subset of current 
Bitcoin
Script not extension.

At the very least, and in reference to what is described in naumenkogs's 
original
TxWithhold article, the introduction of OP_CSFS let you have m-of-n oracles 
doing
attestations in the script that a block has been confirmed, eventually with 
a tx.
This is already a powerful building block for TxWithhold. At first thought, 
I don't
see how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design 
the scope
is reduced.

On the distinction between execution risks with crypto-economic incentives 
risks
brought by some on this thread, this is unclear what is meant exactly. Of 
course
with execution risks, it might more think affecting full-node security (e.g 
a DoS
vector, reason a lot of opcodes were disabled back in ~2010), though it 
could be
just a risk of misuage of the primitive by use-cases toolchain (e.g 
generating 
a consensus-invalid tx due to misuse of the timelock flags) or an attack 
driven
by crypto-ecnomic incentives (e.g selfish-mining or block-withholding 
attack at
the miner-level). Though even for a simple DoS, one can evaluate the CPU / 
bandwidth
cost in quantitative terms to gauge if it's a serious risk, there is an 
area of
uncertainty, or it's not a risk.

When we we talk about security risks, one has to see things that it's more 
a continuum,
where an attacker vector can be used as a building block for more 
sophisticated
attacks. In the original bitcoin paper, crypto-incentives themselves are 
weighted
to evaluate the soundness of the system in section 6. and in section 11.

Best,
Antoine
OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d7b4d448f2895a1b70b2886e9d8

Le jeudi 6 mars 2025 à 19:03:48 UTC, moonsettler a écrit :

> Hi All,
>
> > I am less persuaded that consensus risk is particularly high for very 
> narrowly scoped changes
> Agreed.
>
> Some people out there seem to conflate execution risks with 
> crypto-economic incentives risks.
> Better designed script systems obviously reduce execution risks and 
> unintended consensus failure risks and make maintenance easier.
> They also quiet easily blow the lid off other types of risks by nature of 
> being better and more capable.
>
> Paradoxically the more expressive bitcoin script becomes over time, the 
> less likely that a script system overhaul comes with a nasty surprise.
>
> BR,
> moonsettler
>
>
> On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsand...@gmail.com> 
> wrote:
>
> > > Of course it depends on the specifics, but rewriting a clean 
> interpreter that we can actually reason about does not strike me as a 
> necessarily riskier approach than "just changing a few lines of code" in an 
> interpreter that hardly anyone knows how it really behaves in all cases.
> > 
> > It's certainly something to consider when weighing further off Bitcoin 
> Script updates: From here is something like "Great Script Restoration" ever 
> the right choice vs a from scratch overhaul? I am less persuaded that 
> consensus risk is particularly high for very narrowly scoped changes, 
> ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil 
> risks, etc. The risk-reward ratio may be suboptimal of course.
> > Greg
> > On Wednesday, March 5, 2025 at 11:39:27 AM UTC-5 Antoine Poinsot wrote:
> > 
> > > Hi,
> > > 
> > > 
> > > Just picking on one thing Laolu said:
> > > 
> > > > The current Overton Window appears to be focused on a small (LoC 
> wise) package to enable a greater degree of permissionless innovation on 
> Bitcoin
> > > 
> > > 
> > > For what it's worth i'm not sure this is the correct focus. Bitcoin 
> Script is so notoriously unpredictable and hard to reason about that most 
> of what matters is outside of the lines of code changed. Of course it 
> depends on the specifics, but rewriting a clean interpreter that we can 
> actually reason about does not strike me as a necessarily riskier approach 
> than "just changing a few lines of code" in an interpreter that hardly 
> anyone knows how it really behaves in all cases.
> > > 
> > > Antoine
> > > 
> > > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <
> lao...@gmail.com> wrote:
> > > 
> > > > Hi AJ,
> > > > 
> > > > First a standard disclaimer: the contents of this email shouldn't be
> > > > interpreted as an endorsement of one covenants proposal over another.
> > > > 
> > > > > Since BIP 119's motivation is entirely concerned with its concept 
> of
> > > > > covenants and avoiding what it calls recursive covenants
> > > > 
> > > > If we look at the motivation section of BIP 119, we find this 
> sentence:
> > > > 
> > > > > This BIP introduces a simple covenant called a *template* which 
> enables a
> > > > > limited set of highly valuable use cases without significant risk. 
> BIP-119
> > > > > templates allow for non-recursive fully-enumerated covenants with 
> no
> > > > > dynamic state.
> > > > 
> > > > You appear to have latched onto the "non-recursive" aspect, ignoring 
> the
> > > > subsequent qualifiers of "fully-enumerated" and "with no dynamic 
> state".
> > > > 
> > > > The example that you've come up with to "directly undermine" the 
> claimed
> > > > motivations of BIP 119 is still fully enumerated (the sole state is 
> declared
> > > > up front), and doesn't contain dynamic state (I can't spend the 
> contract on
> > > > chain and do something like swap in another hash H, or signature S).
> > > > 
> > > > > I found it pretty inconvenient, which I don't think is a good 
> indication
> > > > > of ecosystem readiness wrt deployment. (For me, the two components 
> that
> > > > > are annoying is doing complicated taproot script path spends, and
> > > > > calculating CTV hashes)
> > > > 
> > > > What language/libraries did you use to produce the spend? In my own
> > > > development tooling of choice, producing complicated taproot script 
> path
> > > > spends is pretty straight forward, so perhaps the inconvenience you 
> ran into
> > > > says more about your dev tooling than the ecosystem readiness.
> > > > 
> > > > It's also worth pointing out that your example relies on private key
> > > > deletion, which if deemed acceptable, can be used to emulate CTV as 
> is today
> > > > (though you can't create a self-referential loop that way afaict).
> > > > 
> > > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > > approach for the long term
> > > > 
> > > > Simplicity certainly has some brilliant devs working on it, but 
> after all
> > > > these years it still seems to be struggling to exit research mode 
> with some
> > > > "killer apps" on Liquid.
> > > > 
> > > > bllsh on the other hand is a very new (and cool!) project that has no
> > > > development uptake beyond its creator. Given its nascent state, it 
> seems
> > > > rather premature to promote it as a long term solution.
> > > > 
> > > > Both of them are effectively a complete rewrite of Script, so 
> compared to
> > > > some of the existing covenant proposals on the table (many of which 
> have a
> > > > small core code footprint in the interpreter), they represent a 
> radically
> > > > expanded scope (ecosystem changes, wallets, consensus code) and 
> therefore
> > > > additional risks. The current Overton Window appears to be focused 
> on a
> > > > small (LoC wise) package to enable a greater degree of permissionless
> > > > innovation on Bitcoin, while leaving the research landscape open for 
> more
> > > > dramatic overhauls (bllsh/Simplicity) in the future.
> > > > 
> > > > -- Laolu
> > > > 
> > > > 
> > > > On Tue, Mar 4, 2025 at 5:06 PM Anthony Towns <a...@erisian.com.au> 
> wrote:
> > > > 
> > > > > Hello world,
> > > > > 
> > > > > Some people on twitter are apparently proposing the near-term 
> activation of
> > > > > CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> > > > > 
> > > > > https://x.com/JeremyRubin/status/1895676912401252588
> > > > > https://x.com/lopp/status/1895837290209161358
> > > > > https://x.com/stevenroose3/status/1895881757288996914
> > > > > https://x.com/reardencode/status/1871343039123452340
> > > > > https://x.com/sethforprivacy/status/1895814836535378055
> > > > > 
> > > > > Since BIP 119's motivation is entirely concerned with its concept 
> of
> > > > > covenants and avoiding what it calls recursive covenants, I think 
> it
> > > > > is interesting to note that the combination of CSFS and CTV 
> trivially
> > > > > enables the construction of a "recursive covenant" as BIP 119 uses 
> those
> > > > > terms. One approach is as follows:
> > > > > 
> > > > > * Make a throwaway BIP340 private key X with 32-bit public key P.
> > > > > * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", 
> and
> > > > > its corresponding scriptPubKey K when combined with P as the 
> internal public
> > > > > key.
> > > > > * Calculate the CTV hash corresponding to a payment of some 
> specific value V
> > > > > to K; call this hash H
> > > > > * Calculate the BIP 340 signature for message H with private key 
> X, call it S.
> > > > > * Discard the private key X
> > > > > * Funds sent to K can only be spent by the witness data "<H> <S>" 
> that forwards
> > > > > an amount V straight back to K.
> > > > > 
> > > > > Here's a demonstration on mutinynet:
> > > > > 
> > > > > 
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> > > > > 
> > > > > I'd encourage people to try implementing that themselves with their
> > > > > preferred tooling; personally, I found it pretty inconvenient, 
> which I
> > > > > don't think is a good indication of ecosystem readiness wrt 
> deployment.
> > > > > (For me, the two components that are annoying is doing complicated
> > > > > taproot script path spends, and calculating CTV hashes)
> > > > > 
> > > > > I don't believe the existence of a construction like this poses any
> > > > > problems in practice, however if there is going to be a push to 
> activate
> > > > > BIP 119 in parallel with features that directly undermine its 
> claimed
> > > > > motivation, then it would presumably be sensible to at least update
> > > > > the BIP text to describe a motivation that would actually be 
> achieved by
> > > > > deployment.
> > > > > 
> > > > > Personally, I think BIP 119's motivation remains very misguided:
> > > > > 
> > > > > - the things it describes are, in general, not "covenants" [0]
> > > > > - the thing it avoids is not "recursion" but unbounded recursion
> > > > > - avoiding unbounded recursion is not very interesting when 
> arbitrarily
> > > > > large recursion is still possible [1]
> > > > > - despite claiming that "covenants have historically been widely
> > > > > considering to be unfit for Bitcoin", no evidence for this claim 
> has
> > > > > been able to be provided [2,3]
> > > > > - the opposition to unbounded recursion seems to me to either 
> mostly
> > > > > or entirely be misplaced fear of things that are already possible 
> in
> > > > > bitcoin and easily avoided by people who want to avoid it, eg [4]
> > > > > 
> > > > > so, at least personally, I think almost any update to BIP 119's 
> motivation
> > > > > section would be an improvement...
> > > > > 
> > > > > [0] 
> https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/
> > > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/
> > > > > [2] 
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses.com/
> > > > > [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> > > > > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/
> > > > > 
> > > > > Beyond being a toy example of a conflict with BIP 119's motivation
> > > > > section, I think the above script could be useful in the context 
> of the
> > > > > "blind-merged-mining" component of spacechains [5]. For example, if
> > > > > the commitment was to two outputs, one the recursive step and the 
> other
> > > > > being a 0sat ephemeral anchor, then the spend of the ephemeral 
> anchor
> > > > > would allow for both providing fees conveniently and for encoding 
> the
> > > > > spacechain block's commitment; competing spacechain miners would 
> then
> > > > > just be rbf'ing that spend with the parent spacechain update 
> remaining
> > > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV 
> would
> > > > > need to be used to ensure the "one spacechain update per bitcoin 
> block"
> > > > > rule. (I believe mutinynet doesn't support ephemeral anchors 
> however, so
> > > > > I don't think there's anywhere this can be tested)
> > > > > 
> > > > > [5] 
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
> > > > > 
> > > > > (For a spacechain, miners would want to be confident that the 
> private key
> > > > > has been discarded. This confidence could be enhanced by creating 
> X as a
> > > > > musig2 key by a federation, in which case provided any of the 
> private keys
> > > > > used in generating X were correctly discarded, then everything is 
> fine,
> > > > > but that's still a trust assumption. Simple introspection opcodes 
> would
> > > > > work far better for this use case, both removing the trust 
> assumption
> > > > > and reducing the onchain data required)
> > > > > 
> > > > > If you're providing CTV and CSFS anyway, I don't see why you 
> wouldn't
> > > > > provide the same or similar functionality via a SIGHASH flag so 
> that you
> > > > > can avoid specifying the hash directly when you're signing it 
> anyway,
> > > > > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > > > > 
> > > > > (Likewise, I don't see why you'd want to activate CAT on mainnet 
> without
> > > > > also at least re-enabling SUBSTR, and potentially also the 
> redundant
> > > > > LEFT and RIGHT operations)
> > > > > 
> > > > > For comparison, bllsh [6,7] takes the approach of providing
> > > > > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" 
> (same but
> > > > > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A 
> CTV
> > > > > equivalent would then either involve simplying writing:
> > > > > 
> > > > > (= (bip342_txmsg 3) 0x.....)
> > > > > 
> > > > > meaining "calculate the message hash of the current tx for 
> SIGHASH_SINGLE,
> > > > > then evaluate whether the result is exactly equal to this constant"
> > > > > providing one of the standard sighashes worked for your use case, 
> or
> > > > > replacing the bip342_txmsg opcode with a custom calculation of the 
> tx
> > > > > hash, along the lines of the example reimplementation of 
> bip342_txmsg
> > > > > for SIGHASH_ALL [8] in the probably more likely case that it 
> didn't. If
> > > > > someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> > > > > be happy to include that as an example; I think it should be a 
> pretty
> > > > > straightforward conversion from the test-tx example.
> > > > > 
> > > > > If bllsh were live today (eg on either signet or mainnet), and it 
> were
> > > > > desired to softfork in a more optimised implementation of either 
> CTV or
> > > > > ANYPREVOUT to replace people coding their own implementation in 
> bllsh
> > > > > directly, both would simply involve replacing calls to 
> "bip342_txmsg"
> > > > > with calls to a new hash calculation opcode. For CTV behaviour, 
> usage
> > > > > would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO 
> behaviour,
> > > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". 
> That
> > > > > is, the underlying "I want to hash a message in such-and-such a 
> way"
> > > > > looks the same, and how it's used is the wallet author's decision,
> > > > > not a matter of how the consensus code is written.
> > > > > 
> > > > > I believe simplicity/simfony can be thought of in much the same 
> way;
> > > > > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like 
> behaviour
> > > > > [9], or "jet::eq_256" comparing a tx hash and a constant for 
> CTV-like
> > > > > behaviour [10].
> > > > > 
> > > > > [6] https://github.com/ajtowns/bllsh/
> > > > > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> > > > > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> > > > > [9] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> > > > > [10] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
> > > > > 
> > > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > > approach for the long term, and the ongoing lack of examples of 
> killer
> > > > > apps demonstrating big wins from limited slices of new 
> functionality
> > > > > leaves me completely unexcited about rushing something in the 
> short term.
> > > > > Having a flood of use cases that don't work out when looked into 
> isn't
> > > > > a good replacement for a single compelling use case that does.
> > > > > 
> > > > > 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+...@googlegroups.com.
> > > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au
> .
> > > > 
> > > > --
> > > > 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+...@googlegroups.com.
> > > 
> > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com
> .
> > 
> > --
> > 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+...@googlegroups.com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com
> .
>

-- 
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/7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 31528 bytes --]