From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 06 Mar 2025 11:03:57 -0800 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tqGVg-0007Lc-61 for bitcoindev@gnusha.org; Thu, 06 Mar 2025 11:03:57 -0800 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-60041dfef50sf881680eaf.0 for ; Thu, 06 Mar 2025 11:03:56 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1741287830; cv=pass; d=google.com; s=arc-20240605; b=dEWO0y59DkCHgJK+bKtZI2Gvk4wci9UHKVvRPNoBi05RwWTeoXX5ieo71kONhsQANa wTBc2C4Yq5DoLAiBrqZtBjnrrKpc5baON2f5mi5fsXtHGJuCCFmxhWhFfE4ufVQD0aQA 5wB8VQRuQm3bW5lW4Y7qHBzx+q26igWHweReuV/420q2GTDoJFGE7t7d8B927CyN198U PLpU57W+dWnefD5XAWcHbIUtTEyEQdooq7gX6Bk/3baSjxfjMUgKQKXXTHWU0AJbXND2 AC+dbRhJP7SDJJ6Mt7nv9dm5HeCu3b0mkwTSs2U+yVfi4Iy5Q83FeKL6hxRatDTXX20m uLyA== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=; fh=mK1YCV2SAcJu/sZA5qIZrBO3uS1wOAk4E9oaLyZLae4=; b=Onr2oQv9G9EsJM1eQ3FkSK9oEcy5hXgLa0yJNLsG+tlEH5+Wcr5U/hcdvNSsqkBIkm AsHcmShNVCHp5VviptqPgQ1RC/zvq48MC2uNwIYDQDDpWXK2Fe0hF6/qocLLcqWWo1Bb CcLTPkCGfIAzD6N9vUSO4fv0Y53YTttdh3LpJ5nH0d7PTpQoXUFAx4sv9G3xpIJorJyn eUJRjo5EbJQWJ9Phm7i5Klpd+HOEUJxplIZn1/9/lSwH9ze4brVESEF3PSWKk0V42qeL GJqIsyEi+L79DO3S/gFexAZ5iJaysliolvq2e6OTRlYwOMTNGNP0GrDnYm7CLv7jEhtx AnHA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@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=1741287830; x=1741892630; 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 :content-transfer-encoding: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=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=; b=jXk2fnV++6C/GbOLlQ0mQhxpegf0yJrvSErV3NZ+hivT1y9+2QZM++fpytqpoJ2lTL XkWhSOZ2wGYFIY6qAQJ/9y8YMmbFWXGhaSal4xcwmGc+/g0NJUadKTENBoexLkvYcta1 GqBB6LJg2ctSVABVCeYnNuIclzEpd0cYene14cUHEKFF0KYv6sIA7iUb1zubdbX7zdEd WaMG66JS7kxhDJB3b3dfLOAYMuBNaiV+vGbMd0GZNJVp/tcGhQDGUcnwbw7/IfC1AXOE nLAS/KcjKaePC/IKyhNU82HG3I9hoBkU5olngeMFDPYa2DHjxadqBauy5ev0fZ+dCWAw iFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741287830; x=1741892630; 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 :content-transfer-encoding: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=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=; b=Eg8WTQBT4Nd2/8mhfPS4K5rDOBfG/0yQ4zQtYluomU64WNFY/0VYcP6v3SeZmFn+eM bPsI1y3GENsjOAA43+at701nU4J8kemBA+TMwSv53qKTDTKQ1TX1HewnAVldENjMGM/K 8OSw4gam1tCnnCtAaUEOZJffOaNwtu0DFgkKQ8+eSuKZ3zIxutT4FGoPBkwzaYqFAteh HOamXquL3ch1KjtV2GJ7e0rzLZ6+KuNUUkc4wezmJQIzIivMVQJF04ekFqNa05UD8etG 41jrch+hOHE/ObQgZKHnu/EvCOB34ZjxIQyj3nQpiyDXTgfr0uKmYWTTP2S5Uybzsj1v K4Yg== X-Forwarded-Encrypted: i=2; AJvYcCXlN2mB3gT5UdsjJ/7Si6LDpkv8EW+KRbWrXa8pljLhVN3en/Y0BxcmaTYhz8CMnbFRIWaIVtsmLKfd@gnusha.org X-Gm-Message-State: AOJu0YyeWHo9Pv0ZD/+g2bv6IyQCyp86Gp/RaFWqvUL2KDZzQAHOxVTu nShEl++hmwoNZoM1CFerSeu363N/HdgsN1Thocg/qnj8zThQ3l7w X-Google-Smtp-Source: AGHT+IGsFRW0uVx7MYLBMnlPdmAXsIBXv8wkMXersIc+6geFepq2uSXqECtE4Cj+4rYX7SX7uoqkbw== X-Received: by 2002:a05:6820:2711:b0:5fe:9d0b:f7a with SMTP id 006d021491bc7-6004a773d0fmr274800eaf.2.1741287828770; Thu, 06 Mar 2025 11:03:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVF37z4xPt8mJeu0/bk9LvfsiAty8NWtJ7vG9xmaEcHkpg== Received: by 2002:a05:6820:229c:b0:600:108d:824b with SMTP id 006d021491bc7-6003e89de89ls564903eaf.0.-pod-prod-05-us; Thu, 06 Mar 2025 11:03:46 -0800 (PST) X-Received: by 2002:a05:6808:3986:b0:3f3:d275:d873 with SMTP id 5614622812f47-3f697b5d5fbmr396243b6e.17.1741287826445; Thu, 06 Mar 2025 11:03:46 -0800 (PST) Received: by 2002:a50:d759:0:b0:5d9:ef28:b33e with SMTP id 4fb4d7f45d1cf-5e59e6bc0admsa12; Thu, 6 Mar 2025 10:36:22 -0800 (PST) X-Received: by 2002:a17:907:1c1f:b0:ac2:1793:adc3 with SMTP id a640c23a62f3a-ac252fb9688mr10356366b.41.1741286180100; Thu, 06 Mar 2025 10:36:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1741286180; cv=none; d=google.com; s=arc-20240605; b=k1G2gyIqO+vU1XFIUh0Ym7/UdXmuwoN4dT7UQ/5JZHkFJ+szU5huTqYq27585h58C6 FhZ5kpXYZzXqfn+3lZISZ2mAN8kw0PkTQJNN7O/lOyaMWn1DlXsFkBzQLTwtOQbZPMLF vNO5z7JHPzwGmoru+GUhWTwASnuKI2txvItRIUnISX72ed3trRxAtFxwrdHMxzoE23xx YDAdpvzoBIURYhPNZhANfbzS1/9UbrguEN+nHnawc5AK/SF6vK6Cxpt32NoPZQYHZpSq GmK9zAEiQQ0oxrF0DQNh8EU33GF487J5ZeF8wGan3uFCSEMQgv/lvOQze3um+wMEcjER E6pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=/w5R5jDabCkhMOkb9KsLxCm1ZWrDinEzTi2Z07WB3A4=; fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=; b=bayRwYSm4j79IhvBEKk6htkqzYkmwEu2gOs0dI/8nBzm7mggoIUxFU59e6WisWRaPc 4zKeog4D9qqo9+UjotIAIPKDNuzKWeQgkZ/R38taT/3xecdUVjz2pc7+pRP4YLD3qBLW XWveEV9waiJpVMo3eaejj4G984M1ZUPqvuUz+i9KhN/bMHJghwGSTQ+jqUNDjgXMvTGo XANwzwwI1QQD5DCjjRONKEu1GMaJLmHv5iSHRXoinhXBHijOk/I9jr1IDPWnzI/mZoXY BAuEjhUBa543rdHRmgP2QAxzRvj0WKsjmrQkm+4bdKOJc2zxOdDJO4KzfHaaxH5z3iqr 0uIg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch. [185.70.40.137]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-ac23913076asi3690266b.0.2025.03.06.10.36.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Mar 2025 10:36:20 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) client-ip=185.70.40.137; Date: Thu, 06 Mar 2025 18:36:15 +0000 To: Greg Sanders From: "'moonsettler' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS Message-ID: In-Reply-To: <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com> References: <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com> <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 23a02cddfb57720ecf4ce31fd1239f1629eb8fe5 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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 (-) Hi All, > I am less persuaded that consensus risk is particularly high for very nar= rowly 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 uninten= ded consensus failure risks and make maintenance easier. They also quiet easily blow the lid off other types of risks by nature of b= eing better and more capable. Paradoxically the more expressive bitcoin script becomes over time, the les= s likely that a script system overhaul comes with a nasty surprise. BR, moonsettler On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders wrote: > > Of course it depends on the specifics, but rewriting a clean interprete= r that we can actually reason about does not strike me as a necessarily ris= kier approach than "just changing a few lines of code" in an interpreter th= at hardly anyone knows how it really behaves in all cases. >=20 > It's certainly something to consider when weighing further off Bitcoin Sc= ript updates: From here is something like "Great Script Restoration" ever t= he right choice vs a from scratch overhaul? I am less persuaded that consen= sus risk is particularly high for very narrowly scoped changes, ignoring th= e "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=E2=80=AFAM UTC-5 Antoine Poinsot = wrote: >=20 > > Hi, > >=20 > >=20 > > Just picking on one thing Laolu said: > >=20 > > > The current Overton Window appears to be focused on a small (LoC wise= ) package to enable a greater degree of permissionless innovation on Bitcoi= n > >=20 > >=20 > > For what it's worth i'm not sure this is the correct focus. Bitcoin Scr= ipt is so notoriously unpredictable and hard to reason about that most of w= hat matters is outside of the lines of code changed. Of course it depends o= n the specifics, but rewriting a clean interpreter that we can actually rea= son about does not strike me as a necessarily riskier approach than "just c= hanging a few lines of code" in an interpreter that hardly anyone knows how= it really behaves in all cases. > >=20 > > Antoine > >=20 > > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun wrote: > >=20 > > > Hi AJ, > > >=20 > > > First a standard disclaimer: the contents of this email shouldn't be > > > interpreted as an endorsement of one covenants proposal over another. > > >=20 > > > > Since BIP 119's motivation is entirely concerned with its concept o= f > > > > covenants and avoiding what it calls recursive covenants > > >=20 > > > If we look at the motivation section of BIP 119, we find this sentenc= e: > > >=20 > > > > This BIP introduces a simple covenant called a *template* which ena= bles a > > > > limited set of highly valuable use cases without significant risk. = BIP-119 > > > > templates allow for non-recursive fully-enumerated covenants with n= o > > > > dynamic state. > > >=20 > > > You appear to have latched onto the "non-recursive" aspect, ignoring = the > > > subsequent qualifiers of "fully-enumerated" and "with no dynamic stat= e". > > >=20 > > > The example that you've come up with to "directly undermine" the clai= med > > > motivations of BIP 119 is still fully enumerated (the sole state is d= eclared > > > up front), and doesn't contain dynamic state (I can't spend the contr= act on > > > chain and do something like swap in another hash H, or signature S). > > >=20 > > > > I found it pretty inconvenient, which I don't think is a good indic= ation > > > > of ecosystem readiness wrt deployment. (For me, the two components = that > > > > are annoying is doing complicated taproot script path spends, and > > > > calculating CTV hashes) > > >=20 > > > What language/libraries did you use to produce the spend? In my own > > > development tooling of choice, producing complicated taproot script p= ath > > > spends is pretty straight forward, so perhaps the inconvenience you r= an into > > > says more about your dev tooling than the ecosystem readiness. > > >=20 > > > 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 i= s today > > > (though you can't create a self-referential loop that way afaict). > > >=20 > > > > For me, the bllsh/simplicity approach makes more sense as a design > > > > approach for the long term > > >=20 > > > Simplicity certainly has some brilliant devs working on it, but after= all > > > these years it still seems to be struggling to exit research mode wit= h some > > > "killer apps" on Liquid. > > >=20 > > > 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 se= ems > > > rather premature to promote it as a long term solution. > > >=20 > > > Both of them are effectively a complete rewrite of Script, so compare= d to > > > some of the existing covenant proposals on the table (many of which h= ave a > > > small core code footprint in the interpreter), they represent a radic= ally > > > expanded scope (ecosystem changes, wallets, consensus code) and there= fore > > > 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. > > >=20 > > > -- Laolu > > >=20 > > >=20 > > > On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns wrote: > > >=20 > > > > Hello world, > > > >=20 > > > > Some people on twitter are apparently proposing the near-term activ= ation of > > > > CTV and CSFS (BIP 119 and BIP 348 respectively), eg: > > > >=20 > > > > 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 > > > >=20 > > > > Since BIP 119's motivation is entirely concerned with its concept o= f > > > > covenants and avoiding what it calls recursive covenants, I think i= t > > > > is interesting to note that the combination of CSFS and CTV trivial= ly > > > > enables the construction of a "recursive covenant" as BIP 119 uses = those > > > > terms. One approach is as follows: > > > >=20 > > > > * Make a throwaway BIP340 private key X with 32-bit public key P. > > > > * Calculate the tapscript "OP_OVER

OP_CSFS OP_VERIFY OP_CTV", a= nd > > > > its corresponding scriptPubKey K when combined with P as the intern= al public > > > > key. > > > > * Calculate the CTV hash corresponding to a payment of some specifi= c 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 " " t= hat forwards > > > > an amount V straight back to K. > > > >=20 > > > > Here's a demonstration on mutinynet: > > > >=20 > > > > https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd3= 3tznmyjejrmqqx525gsk5nr58 > > > >=20 > > > > I'd encourage people to try implementing that themselves with their > > > > preferred tooling; personally, I found it pretty inconvenient, whic= h I > > > > don't think is a good indication of ecosystem readiness wrt deploym= ent. > > > > (For me, the two components that are annoying is doing complicated > > > > taproot script path spends, and calculating CTV hashes) > > > >=20 > > > > 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 act= ivate > > > > BIP 119 in parallel with features that directly undermine its claim= ed > > > > motivation, then it would presumably be sensible to at least update > > > > the BIP text to describe a motivation that would actually be achiev= ed by > > > > deployment. > > > >=20 > > > > Personally, I think BIP 119's motivation remains very misguided: > > > >=20 > > > > - 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 arbitra= rily > > > > 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 ha= s > > > > been able to be provided [2,3] > > > > - the opposition to unbounded recursion seems to me to either mostl= y > > > > or entirely be misplaced fear of things that are already possible i= n > > > > bitcoin and easily avoided by people who want to avoid it, eg [4] > > > >=20 > > > > so, at least personally, I think almost any update to BIP 119's mot= ivation > > > > section would be an improvement... > > > >=20 > > > > [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/ > > > >=20 > > > > 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 o= ther > > > > being a 0sat ephemeral anchor, then the spend of the ephemeral anch= or > > > > would allow for both providing fees conveniently and for encoding t= he > > > > spacechain block's commitment; competing spacechain miners would th= en > > > > just be rbf'ing that spend with the parent spacechain update remain= ing > > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV w= ould > > > > need to be used to ensure the "one spacechain update per bitcoin bl= ock" > > > > rule. (I believe mutinynet doesn't support ephemeral anchors howeve= r, so > > > > I don't think there's anywhere this can be tested) > > > >=20 > > > > [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906= b16a5#file-bmm-svg > > > >=20 > > > > (For a spacechain, miners would want to be confident that the priva= te 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 priva= te keys > > > > used in generating X were correctly discarded, then everything is f= ine, > > > > but that's still a trust assumption. Simple introspection opcodes w= ould > > > > work far better for this use case, both removing the trust assumpti= on > > > > and reducing the onchain data required) > > > >=20 > > > > 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 tha= t you > > > > can avoid specifying the hash directly when you're signing it anywa= y, > > > > giving an ANYPREVOUT/NOINPUT-like feature directly. > > > >=20 > > > > (Likewise, I don't see why you'd want to activate CAT on mainnet wi= thout > > > > also at least re-enabling SUBSTR, and potentially also the redundan= t > > > > LEFT and RIGHT operations) > > > >=20 > > > > 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: > > > >=20 > > > > (=3D (bip342_txmsg 3) 0x.....) > > > >=20 > > > > 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, o= r > > > > replacing the bip342_txmsg opcode with a custom calculation of the = tx > > > > hash, along the lines of the example reimplementation of bip342_txm= sg > > > > 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 pret= ty > > > > straightforward conversion from the test-tx example. > > > >=20 > > > > If bllsh were live today (eg on either signet or mainnet), and it w= ere > > > > desired to softfork in a more optimised implementation of either CT= V or > > > > ANYPREVOUT to replace people coding their own implementation in bll= sh > > > > directly, both would simply involve replacing calls to "bip342_txms= g" > > > > with calls to a new hash calculation opcode. For CTV behaviour, usa= ge > > > > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO beha= viour, > > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". Tha= t > > > > 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. > > > >=20 > > > > 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 behav= iour > > > > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-li= ke > > > > behaviour [10]. > > > >=20 > > > > [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/exam= ples/p2pk.simf > > > > [10] https://github.com/BlockstreamResearch/simfony/blob/master/exa= mples/ctv.simf > > > >=20 > > > > For me, the bllsh/simplicity approach makes more sense as a design > > > > approach for the long term, and the ongoing lack of examples of kil= ler > > > > apps demonstrating big wins from limited slices of new functionalit= y > > > > 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 is= n't > > > > a good replacement for a single compelling use case that does. > > > >=20 > > > > Cheers, > > > > aj > > > >=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, s= end an email to bitcoindev+...@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/Z8eUQCfCWjdivIzn%40erisian.com.au. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > >=20 > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.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/= Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9Y= SgZpC013Lj4SI_WZR0N1iwbUiNze00tA%3D%40protonmail.com.