From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 05 Mar 2025 08:39:35 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tprmP-0002YQ-OH for bitcoindev@gnusha.org; Wed, 05 Mar 2025 08:39:35 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-5f8d5e499a5sf4978020eaf.2 for ; Wed, 05 Mar 2025 08:39:33 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1741192767; cv=pass; d=google.com; s=arc-20240605; b=jIOTJAEydtS/xFDy901v4Oz6ejcmVqzNenvrpcQSJ4nw29TQf8YtsiAntLxNVOOCRD Ty4MuHJrieMEsYr7oDlKq17qNKS+Ue6F6rkXhg8N8eleZifHlvZG7rqpAqIvIOBc0/7k RdD5iRQgPIabTVvzD4x7/CIWkVEXoOOPAApYn6Z2QxoszeklLyB9KK2R/f/hxc/LiLO5 LLGhvZcF35K2KcXn+aYmOvzk0Z4YEpMeDN+2YOJcVU0At/aqEIUXm9/ylk+wtKlkqexc tRz6ixuPBExXIYxxuj6xVKyPzRtbpQVwX7l/YUJ2wxn7muucLdN8HsznmKR8eJisy6sl D0PA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=; fh=0ZmcZD3ymjSeDp5pI+7DucfF6jwd3aZcshuQOyCMUPs=; b=dbpDRMoycB7wZ0rZ1cjIXLlZd7FytpmHCijRNKkwP69qimpABcuvI+2yfhi+YfxmKv r5t4Do90mPNuV2goT+HsedOrRqE+67N/v5Ui/jKEaE3jCQDRovz1l2Onl+MEqBS6XHzB amrPxrowk6tdDinF0dQuhAFKdL9jPVJmLoUCULHNxNG2o+SU5V15XpP1rJVobEmdJSMM dExV9r2o70aKKzZ2+PNvCSICFBra2MeGSz7Uct2BhKcXqoRdQK0gAoruwQtsXXeDWupt 0r7969UeiNlax9LcVLfQ2oeGwD/O8aMz2yxgkR52s1Kb8Fy6rBtZVjkbLtPt+2xEyZr1 yzCg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741192767; x=1741797567; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=; b=orhkALhvydB2qqfGLkhgUbQbYszA0+HDd2M/F8pG1vinGkrcD4aKMzfXysQZStI58D Yay/+4RpBuRb9PlDg5w1jwFQAotrAkQ1f5k8VkGpI/kk5sjzdegzis90Wjf0DNClxVK9 1qdlLyPfT0ybglUdgP7tqpvePpyX6RiMZS+X4ZTbPytDijGIpgYhwjJVFKrB7BkapPIS s9cm1mnfyjRcNXJQAdH2+T+4o8ODndbHiN1Ot8xa6LPhmoU37D9g+LCmssN3HdVxm8x0 TNX8ODfOryNP/iL8ahJ7YtEMVajwqO8ZhUVqtx41CDiwQcHdOUlIUxhsU+eg3yjuUUnk SyAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741192767; x=1741797567; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=; b=pFHRZ0FDraUlRHqZgpHHbSmv0hXMSzxaHCJl/TO7xTDGdF9etM8I3HLheOKr94w9Ld 2v9nAKpZxMou6bSYXEwEq4vNLmVZBNyHu81wcMN4XXTSoi61TtRJcI1Zbu0S3WYxlacn s9X9LaVzaWEEA2N782xt5L+b6AE7iTbJDe7GSLK75eoetpyFJUw685up+CDZUd//Pn2R dmtPIA7DZ94PxReO5X4OR+mPkhwcUMvsdg+Mf8LAM4ny3+8V+9S9G2QJLrYc21qAV9FH J11PKVo7IAyFdSaRKTBCjXyKmZRrB0J5SZf75HjV96claSIRZuSryJiSavEnfxiJgLpZ KxVw== X-Forwarded-Encrypted: i=2; AJvYcCV1E/Z7yvlbJLbkrLo/0g914eK+Vewg5SvOmJDyoavcg80JdC7He74DqxpZ7ClWaOSsrfDqdpeYLcn4@gnusha.org X-Gm-Message-State: AOJu0Yzph3jV8mtZMf0VUo4VuiM4gh+VSfDtE/k1+xk3kxzrpcQssWTY YFeUuKSyUek3KhG1TKGvSEOZgT9LE2aTZ5+dnQSJZ29JjWYaXQgJ X-Google-Smtp-Source: AGHT+IEhea8yBMsxo8e1vYPxSE2SVb78ohl8YjwocfIvTJlbAlXcFAExmhBlFQqt7muu2sJ+RrB7aQ== X-Received: by 2002:a05:6820:180b:b0:5fe:9a72:3dea with SMTP id 006d021491bc7-600334786e6mr2037053eaf.1.1741192767235; Wed, 05 Mar 2025 08:39:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEpJk5+08jQLFrnQDQRboZ0xTVAatb4fsi89eQIqkU76g== Received: by 2002:a4a:a508:0:b0:600:38e0:9fba with SMTP id 006d021491bc7-6003ea298e8ls890eaf.2.-pod-prod-08-us; Wed, 05 Mar 2025 08:39:24 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWg404PhOoYCFADGY56OKZgrdLxJtYaxatbE9oFIwCyol7i14uNQEhSLJCe11cjjqXdfgZRqnXjIfh6@googlegroups.com X-Received: by 2002:a05:6808:211c:b0:3f4:1b5f:9336 with SMTP id 5614622812f47-3f683157233mr2353495b6e.10.1741192764311; Wed, 05 Mar 2025 08:39:24 -0800 (PST) Received: by 2002:a50:d4d9:0:b0:5d0:c760:dcfa with SMTP id 4fb4d7f45d1cf-5e59e69922fmsa12; Wed, 5 Mar 2025 08:14:36 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXcLaz8hriE/zmKJZtARljBoJV2RrpbOXmF4lsgFcmea7i82oWsnJ5i/HFphWEGrxLeKoWyS8vBOE76@googlegroups.com X-Received: by 2002:a05:6402:3490:b0:5de:3c29:e834 with SMTP id 4fb4d7f45d1cf-5e59f486c04mr4009424a12.27.1741191273895; Wed, 05 Mar 2025 08:14:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1741191273; cv=none; d=google.com; s=arc-20240605; b=USt1EQoIihT0IY8psmmAs3GqvN3g3LSD2SEhQb1pHogOHf+U6/XzB6T73BPCfL1ib8 9zmtbEKjL8HhycZ14qaDj6S1Okt3G8i/mOUQ8XYfFgaEu/uuzicDkHZpJNsPoU9xfmAN Y3bsJv3py1Odx1vW8tTvo7a09ONLCuDd/z1G/iaKReyf94/Xhllg3UZ8VH47KHfKIxzl d7XwFxTV+NuQC7V647MWM+zssWNO5nN6ZXt4MbhkbtzbJz3F3DqmeWVrwA25IPwVXAWr NiPUH14NiFQ9ic87uYL0ObDiN36uz1d6A+R0wuuMKEPsFBtbefwVxDP4DJnwATHD6Dqc ssQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=Rr6y2IFibHhIOC0HjwziiiHH5YFpByjiUDevbh0utQU=; fh=88ulwFhtu4sa9m0DaXx398b7a6WEA2oL1r9zBcWUF+A=; b=dJkkglDKq9stJjF21l/iXfwPgqVFvP1LOneGCuiBu+y6iPiX+v7ywAwHk5N6Dw4EDD IbJLUtRTZ4cf4OGrL5P39oi9RkNkZOGFzkkf6yxIy6XBdq3gRm9Er0PGjVeHA318iz10 CCIuESNpKy+lrKU5j55fSqylpv8deG+TxvGT2WPKrZg3dLyfbbo09fb21L5lPRqjslOe OCs7FeMpkmBO/OHY7gy2TCCOmwCTwzAtRQzdofv1/s3yLt72hD4eMb60dxdMufKoFnSd UlaSeMCguhTPs/F1rjmX2cceIJBDPU3BKkjRncQBDQ/Ep5DczBVxcUySv08+602IPTYd 8BfQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-5e4c3b9d63fsi689845a12.2.2025.03.05.08.14.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 08:14:33 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Wed, 05 Mar 2025 16:14:26 +0000 To: Olaoluwa Osuntokun From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Anthony Towns , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS Message-ID: <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com> In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 0f5d15d4037617c951770d7266254d873b1d9fca MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just picking on one thing Laolu said: > The current Overton Window appears to be focused on a small (LoC wise) pa= ckage 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 th= e specifics, but rewriting a clean interpreter that we can actually reason = about does not strike me as a necessarily riskier approach than "just chang= ing 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 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-1= 19 >> 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 decla= red > 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 i= nto > 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 to= day > (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 so= me > "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=E2=80=AFPM 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 pu= blic >> key. >> * Calculate the CTV hash corresponding to a payment of some specific val= ue 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 f= orwards >> an amount V straight back to K. >> >> Here's a demonstration on mutinynet: >> >> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznm= yjejrmqqx525gsk5nr58 >> >> 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 motivati= on >> 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.a= u/ >> >> 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 ke= y >> 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 ke= ys >> 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: >> >> (=3D (bip342_txmsg 3) 0x.....) >> >> meaining "calculate the message hash of the current tx for SIGHASH_SINGL= E, >> 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 "(=3D (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 Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bun= subscribe@googlegroups.com). >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/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/bitcoinde= v/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLo= QhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com. --b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

Just picking o= n one thing Laolu said:
The current Overton Window appears to be focuse= d on a small (LoC wise) package to enable a greater degree of permissionles= s innovation on Bitcoin

For what it's worth= i'm not sure this is the correct focus. Bitcoin Script is so notoriously u= npredictable 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 re= writing a clean interpreter that we can actually reason about does not strike me as a necessarily riskier approach than "just changing a few li= nes of code" in an interpreter that hardly anyone knows how it really behav= es in all cases.

Antoine
=20
=20
=20
On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <la= olu32@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 motivat= ion is entirely concerned with its concept of
> covenants and avoidin= g what it calls recursive covenants

If we look at the motivation sec= tion 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
> templat= es allow for non-recursive fully-enumerated covenants with no
> dynam= ic state.

You appear to have latched onto the "non-recursive" aspec= t, ignoring the
subsequent qualifiers of "fully-enumerated" and "with no= dynamic state".

The example that you've come up with to "directly u= ndermine" 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 anoth= er hash H, or signature S).

> I found it pretty inconvenient, whi= ch I don't think is a good indication
> of ecosystem readiness wrt de= ployment. (For me, the two components that
> are annoying is doing co= mplicated taproot script path spends, and
> calculating CTV hashes)
What language/libraries did you use to produce the spend? In my owndevelopment tooling of choice, producing complicated taproot script path<= br>spends is pretty straight forward, so perhaps the inconvenience you ran = into
says more about your dev tooling than the ecosystem readiness.
<= br>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 toda= y
(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 br= illiant 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 seem= s
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
sm= all core code footprint in the interpreter), they represent a radically
= expanded scope (ecosystem changes, wallets, consensus code) and thereforeadditional risks. The current Overton Window appears to be focused on asmall (LoC wise) package to enable a greater degree of permissionless
= innovation on Bitcoin, while leaving the research landscape open for moredramatic overhauls (bllsh/Simplicity) in the future.

-- Laolu
<= /div>


O= n Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns <aj@erisian.com.au> wrote:
Hel= lo 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/sta= tus/1895676912401252588
https://x.com/lopp/status/1895837290= 209161358
https://x.com/stevenroose3/s= tatus/1895881757288996914
https://x.com/reardencode/sta= tus/1871343039123452340
https://x.com/sethforpriva= cy/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", an= d
its corresponding scriptPubKey K when combined with P as the internal pu= blic
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 i= t S.
* Discard the private key X
* Funds sent to K can only be spent by the witness data "<H> <S&g= t;" that forwards
an amount V straight back to K.

Here's a demonstration on mutinynet:

https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5= jd33tznmyjejrmqqx525gsk5nr58

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<= br> 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/010001= 7ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/=
[3] https://x.com/Ethan_Heil= man/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#fil= e-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<= br> 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:

(=3D (bip342_txmsg 3) 0x.....)

meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,<= br> 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 "(=3D (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://delvingbitcoi= n.org/t/debuggable-lisp-scripts/1224
[8] https://github.co= m/ajtowns/bllsh/blob/master/examples/test-tx
[9] h= ttps://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.sim= f
[10] h= ttps://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 e= mail to bitcoindev+unsubscribe@goo= glegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8eU= QCfCWjdivIzn%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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups= .google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgC= HWxNV_Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLo= QhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com.
--b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo--