For some historical context, it's interesting to note that CTV originally had the constexpr requirement which prevented your CSFS+CTV construct by requiring the CTV hash to come from a literal push preceding the opcode (i.e. not dynamically computed/pre-verified and not from the witness). This was eventually removed because it was deemed an unnecessary safeguard and to simplify the implementation. Also, it seems that APO alone also enables the same kind of construct as what you're describing. For example, a 'recursive' APO signature spending back to the same address could similarly be used as the basis for a BMM Spacechain. > I'd encourage people to try implementing that themselves with their preferred tooling; personally, I found it pretty inconvenient Here's my go at it using Minsc: https://min.sc/v0.3/#gist=3aa538b384d3aaf4282d1acaf943f608 Example transaction: https://mutinynet.com/tx/9c941dc9c0068eb817b2d18416b174468203c6ad090d8d5735cc9b3732959e39 Note however that what you described is creating 0-fee transactions, with no way to attach additional fees. So this would also need either an anchor output or a CTV template that allows the inclusion of an additional input, which I did not implement in the gist. > For me, the two components that are annoying is doing complicated taproot script path spends, and calculating CTV hashes I've been working on improving Minsc to make these kinds of things easier. It supports Taproot, CTV, PSBT, Descriptors, Miniscript, raw Script, BIP32, and more. Much of it is still undocumented (the min.sc website is very much outdated), but I have some examples demonstrating different uses that might be of interest: - A simple one that involves calculating CTV hashes and a multi-script Taproot tree: https://min.sc/v0.3/#github=examples/ctv-simple.minsc - More advanced example implementing a CTV vault: https://min.sc/v0.3/#github=examples/ctv-vault.minsc - Another vault, with key delegation using CTV+CSFS+PAIRCOMMIT+INTERNALKEY: https://min.sc/v0.3/#gist=82d92568c2fcba62203157f8df11354e - Decaying multisig using PSBT/Miniscript: https://min.sc/v0.3/#github=examples/3of3-into-2of3.minsc More examples are available on the README: https://github.com/shesek/minsc Cheers, shesek On Wed, Mar 5, 2025 at 3:06 AM Anthony Towns 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

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 " " 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/20220719044458.GA26986@erisian.com.au/ > [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/ > [2] > https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/ > [3] https://x.com/Ethan_Heilman/status/1194624166093369345 > [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@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+unsubscribe@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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGXD5f3EGyUVBc%3DbDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q%40mail.gmail.com.