From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Jun 2025 04:31:43 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uRUXV-0001GB-8S for bitcoindev@gnusha.org; Tue, 17 Jun 2025 04:31:42 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-60d60b8ef64sf2597828eaf.3 for ; Tue, 17 Jun 2025 04:31:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750159895; cv=pass; d=google.com; s=arc-20240605; b=cEiBNj4mutjOJws4GSZKcT0AYgFsP+hQx1ulS6xZPiQfL4nOKpMHFivpDO9TYThdXI TpuUj4HSDNmNBJAf8s6QLHLk6pS6QDW7FKfmsiclO8/3hYDwJgEEFQfhUbIC6ZZS1IaS Cw356Z/1y+sE95BXc0UvQ7bOpwMLkVwdLctufZJ/F18xMe7wYZVMhdN125QrVjXuPSwz +3IxlreH1HquLc5VvboC+48QzP4LrTRZNRWfS2xenYBdxDtk+2eY7Fu0qmhchWm0mZaA vdcq9qSIGVhIiCCqXEAEAYORshlZN5uU1NOr2IWkSuI74Tfc7njRyIBc7hQ7CDk3bBB8 PCXA== 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:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=; fh=kjt81XeejoaAGI9UhqEtGhbs4VBzymusSSocoH1pWh8=; b=iW6NlvN44UO3DTYmmtvLgFCLIrHrBZh/w9enjgpjI/Ix1O1A/yDByOHQeaYqdAMqvI +x2AsHEmDNkSAKMnQ0lPXfo3nyPLZPXGemxwVAUE9zWeiIeN+xJSaDRwJd8mHSgZv8LB 4SEqBIv0XS66Z8xQxORE+ty+MEwqTsUJM1diyHBK4/I0RVKsqOzVDOFirEHLcPltzXh5 z0J20C8rR74OIHcRySEOqHhtIL5936Ci3VF1cM1DRibvb3YSR7EV8O0jGIS7HBcdzKms 61uYUmoUL4a9rlm8SJ1kQ5TRZzAzFPFU2UXtLW7iTuIHqsOtw/OlajtPA6yi1yR6x5Vt N8vQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@roose.io header.s=default header.b=ZXzFZ0Ri; spf=pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) smtp.mailfrom=steven@roose.io; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=roose.io DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750159895; x=1750764695; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=; b=DrkyZ22TU3cI7rWUeZUfJXPplPuODb5v8OUQowc5tKxmm6+qs0GClzXGHCLm1juB1U drOxqZRduUGlATPFMW5EM8sAR8Q9AaQTwzzwgdiiPoL2YsOUJ9tHXXo9ncvGv6xdUfDO OWJa0DdOrNtXZObxD6Tq+uB8MqMmUes7D5eQ3QMbnxymCPoY9+zr7kfk33mQ0rgkMD9i eJ7qqo3sAUwiJ1NQwxWxIJw9LufniLLA3lHskHoJUD2CPRTDZy8I47UEYD+/DSBrLMru W0vDm8+sVPLZX5OMeKFGI4c6NcJQ/ZGaTOgZAr/c4druzh22jepW+Hy5wyCI8kHP+AN+ 7oTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750159895; x=1750764695; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=aw7kXnJz24+ijRGt20K/Z9ha8N9Xxm2PfcQdjQy20PY=; b=XDhXKvR5BxKj9X+lpm1rOYdvVhBlS2Eb0HGBhhTKTbI7mwZhm1LOc5YZy5Vb13YLyS WbrOmSsF9qlJlsvyhL/ZKb78XtL3zm+M1eMEydP/LDD8eGnS4ZD01WYdizWqHRAPAGpg 8jeIAYiE835vwVqWNuCZ8Ut9pKYjeYLecrr0KO63dehoV3ewNu7HgYxfPINN8pupZRSh qDtf4zBkw52My2WwwYsNEQ0G+2hw8qL0najG2GHb443pVFVZSnpmJ7cwrqMuxiFuQcYZ 8QtzeGvICAWFLsJKiSKCXZWvy5u+ZTF1uxk63QHS7R6jAX9DpfBd9DFcbR0zVwrHPqyH bQhw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW1u+6uI8UbO8p1C2qb3prWK8jqQ7xq/pY1O8t3HQOWJggq1qeHUX5Vi4OiWSgXOsx02ydI3jLt9MaH@gnusha.org X-Gm-Message-State: AOJu0Yw6xqh69IBhTpF3OYXc4UqsSItNTLEjTQ4otZ6/WGTxuXd9On6R MMuvlrfyqHNsUILPEfq21H2+A2O5Di8Nsjni4Ar4TlgzqQcfNMZTMbqE X-Google-Smtp-Source: AGHT+IEKDGafGXNaTMVydwvJyEvsZOzTxCyw8hr67LwtL0tBja4oG3biNmcj/UAhJdFiVZZpNZl4NQ== X-Received: by 2002:a05:6820:1c9c:b0:610:fbf2:bd7d with SMTP id 006d021491bc7-61110ed108emr7673913eaf.6.1750159895022; Tue, 17 Jun 2025 04:31:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdrziJHNFM2QqOZtMA0wknD1Amljg8VufrypQiWWMuuGQ== Received: by 2002:a05:6820:4982:b0:603:2c01:784b with SMTP id 006d021491bc7-610fd380cfbls914090eaf.2.-pod-prod-02-us; Tue, 17 Jun 2025 04:31:31 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWN1pHosSew6Gloyt+Gp8InCSOPqJ2vqTUEaVf6GReBPGVB+r9mcf1vu9XDHainZA55EiDbaXFukiqW@googlegroups.com X-Received: by 2002:a05:6808:19a5:b0:3fa:daa:dd8e with SMTP id 5614622812f47-40a7c2709b0mr9001440b6e.35.1750159891425; Tue, 17 Jun 2025 04:31:31 -0700 (PDT) Received: by 2002:a05:6808:6091:b0:3f9:f009:458e with SMTP id 5614622812f47-40a7193ecc8msb6e; Tue, 17 Jun 2025 04:22:18 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVLKW+8r0SGqPPH4yG3fp4QeVsFY9YIQe6/eDXnNthM60ID688UYUmM/WyX0W7uMVt6IV3yiRKoX+re@googlegroups.com X-Received: by 2002:a05:6808:508d:b0:408:e68d:975a with SMTP id 5614622812f47-40a7c284a39mr8378107b6e.39.1750159337338; Tue, 17 Jun 2025 04:22:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750159337; cv=none; d=google.com; s=arc-20240605; b=eAV2U0mkIuL9GdgjdgYqmPAOBFFb/mxaPnyMLzTrLiinRzz5tIiqWGzFIjWyrIs1eD h7+1L6MfpXJmWIoAyoJi+rrDeP+9cY//H4ekZqPyaqeRebqLV5bsQcxBKEitRguStKaK bFCltTGvFHnNRbjbvCht53F+3SjNDsUgVWzGneSZvvdgsX51zX3MpwxfzGWXrLFMPXH3 ZtzHEgYMs0AdQoccH4b3+8V3+gR4JZQFg99WoWFHwmnBOM8cxrW2H9/L4PCx2Ajp8AL8 85vZPhTefMOTJkjNdvskQzyfLw20x346ybg9fNg9ar8y0GSxqqNs7ANWdn3AdoJyWW6N hbjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:from:content-language:references:to:subject :mime-version:date:message-id:dkim-signature; bh=BFHsnFC+vZPCdAFP8fezQcYqy3IMsWHuiwE07NSrpiQ=; fh=CyTJ+shPvYF3fdBQQSSAVJMS+eC3Z7H/LTBC0sdqY6M=; b=RruPg+/kziXRfBvmMEe1ivwUF7wI0SRF9jFfEeDgT4TF0ZBN0nNKm+ruxacaEMcnx9 K8Ks8KNA5OWFTvWFjt1rxHy9AluOJsRTKVi2SYd8lq183COHrVdMV0aj66yL6uqRBgKj 5Kek2q+P6hY1aOIED/GunxJTUj+yLliXZlUZan0ZBdZ2jZ/St3XEUxsdIg0mw1iLkiT7 e0n8VPLDYF4vH5n4Vtnb1+37RGREEXTHeJ6C7IktGiTTZwwAOr50sL4KlJGU0BZf7k4l esF5AJC2PYzarzFM1HgqTZzpQUBU5AnkqoHct3xnS3R/h0kh6zr22A6G8aFtZt+sx2Zp iOlQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@roose.io header.s=default header.b=ZXzFZ0Ri; spf=pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) smtp.mailfrom=steven@roose.io; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=roose.io Received: from hosted.mailcow.de (hosted.mailcow.de. [2a00:f820:417::202]) by gmr-mx.google.com with ESMTPS id 5614622812f47-40a740b4f9asi426909b6e.1.2025.06.17.04.22.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jun 2025 04:22:17 -0700 (PDT) Received-SPF: pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) client-ip=2a00:f820:417::202; Received: from [10.151.38.60] (unknown [146.70.129.152]) (Authenticated sender: steven@roose.io) by hosted.mailcow.de (Postcow) with ESMTPSA id 089825C06D0; Tue, 17 Jun 2025 13:22:10 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------WJMLxOyp006ErkFcX1Uwt80c" Message-ID: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io> Date: Tue, 17 Jun 2025 12:22:10 +0100 MIME-Version: 1.0 Subject: Re: [bitcoindev] CTV + CSFS: a letter To: James O'Beirne , Bitcoin Development Mailing List References: Content-Language: en-US From: Steven Roose In-Reply-To: X-Original-Sender: steven@roose.io X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@roose.io header.s=default header.b=ZXzFZ0Ri; spf=pass (google.com: domain of steven@roose.io designates 2a00:f820:417::202 as permitted sender) smtp.mailfrom=steven@roose.io; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=roose.io 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: -0.7 (/) This is a multi-part message in MIME format. --------------WJMLxOyp006ErkFcX1Uwt80c Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hey all I've been following the discussion and noticed TXHASH is mentioned a=20 lot. As a signer of the letter and author of the TXHASH proposal, I'd=20 like to chime in with some thoughts. However, I'd like to first express my disappointment with the amount of=20 drama this letter has caused. It quite literally merely asks Core=20 contributors to put this proposal on their agenda with some urgency. No=20 threats, no hard words. Given that only a handful of Core contributors had thus far participated=20 in the conversation on the proposal elsewhere, it seemed like a suitable=20 next step to communicate that we want Core contributors to provide their=20 position within this conversation. I strongly stand against an approach involving independent activation=20 clients and I think the sentiment of this e-mail aligns with the=20 preference of having Core be involved in any deployment of protocol=20 upgrades. On the proposal itself. I have heard some mentions of TXHASH and why we,=20 as the developer community, wouldn't go=C2=A0 straight for TXHASH. * I think TXHASH is too far from being ready at this point: o The TXHASH BIP and spec has not had the level of review/engagement that I had hoped for. I'm personally pretty happy with the result, especially since it only has had serious looks from myself and Rearden. But it definitely needs a lot more scrutiny. It's a very opinionated design (I think it's unavoidable for such an opcode), so there is a lot of room for making different and maybe better decisions on many fronts. o Once we have the TXHASH semantics, it would be very valuable to consider also introducing the same semantics as a top-level sighash flag system, so you can spend coins directly with a sighash based on TXHASH semantics. (I dubbed this TXSIGHASH and I recently did some simulations on how such a construction would look for fee sponsoring and stacking https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options= -for-sponsorring-and-stacking/1760) o However, this also invites some additional review of possible taproot changes (pay-to-tapscript, re-adding parity byte, ..) and will necessarily take some more time for consideration and design. * I strongly believe it would benefit development of new bitcoin use cases if we would have a simple version of templating and rebindable signatures sooner rather than later. Both BitVM and Ark are fairly recent ideas that stand to benefit significantly from such new functionality, but I think having them actually available will invite a lot more engagement leading to new ideas and new improvements. These are not use case-specific changes, but useful general building blocks. * Both CSFS and CTV are fairly unopinionated opcodes by design, when you think of CTV in the sense that it fixes the minimum tx fields to ensure txid stability. * I think there is both enough excitement for this proposal and there would be enough future excitement for a TXHASH or CCV addition that I don't fear upgrade churn will be a future hurdle. * Even after possible TXHASH activation, I think there will stay some demand for the simpler CTV/TEMPLATEHASH variant. It doesn't just save a byte on the wire, but thinking in a txid-stable model is just more intuitive. I believe that many advanced use cases will take advantage from doing things the TXHASH way (enabling stacking and cheaper fee sponsoring), but some developers will always favor the simplicity of txid stability over the benefits of adding complexity. The above arguments convinced me that an activation based on CTV and=20 CSFS makes sense today. We have lots of developers waiting to make use=20 of the functionality it enables and we can continue development of=20 further changes meanwhile. That being said, I'm in no way married to the exact details of the=20 proposals. * I am sympathetic to worries of changing legacy/v0 script. I failed to convince myself of any valuable usage for bare CTV. * I am sympathetic to the consideration of revisiting scriptSig and annex-related modifications to the template hash. * I am sympathetic to the decision to optimize better for the rebindable signature use cases, meaning: o the idea to swap CTV for a TEMPLATEHASH opcode which adds a 1-byte VERIFY for the template use case but saves 33 bytes for the signature use case o the addition of an INTERNALKEY opcode, saving an additional 33 bytes for the rebindable signature use case All of the above changes I think can be decided on with minimal=20 bikeshedding and still encompass the same semantics of the original=20 proposal. Best Steven On 6/9/25 12:40, James O'Beirne wrote: > Good morning, > > A letter has been published advocating for the final review and > activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK > (BIP-348). > > The full text of the letter can be found at https://ctv-csfs.com. It is > reproduced below. > > --- > > To the technical bitcoin community, > > We believe that the best next step for bitcoin would be to activate > OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CSFS, > BIP-348). These opcodes enable functionality for a broad set of uses > that will allow bitcoin to preserve and expand its role as a scarce, > censorship-resistant store of value. > > While there are a few promising proposals to improve bitcoin at the > consensus layer which may someday be deployed, we believe that CTV and > CSFS are uniquely well reviewed, simple, and have been proven to be both > safe and widely demanded. > > CTV was first formalized in BIP-119 over 5 years ago. Despite many > attempts at refinement or replacement, it has remained the most widely > preferred method for enforcing pregenerated transaction sequences using > consensus. It unlocks valuable functionality for scaling solutions, > vaults, congestion control, non-custodial mining, discreet log > contracts, and more. > > CSFS is a primitive opcode that has been deployed to Blockstream=E2=80=99= s > Elements for at least 8 years. It represents no significant > computational burden over bitcoin=E2=80=99s most often used opcode, OP_CH= ECKSIG. > It can be combined with CTV to implement ln-symmetry, a longstanding > improvement to Lightning. It also unlocks a variety of other use cases. > > We respectfully ask Bitcoin Core contributors to prioritize the review > and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or > similar) within the next six months. We believe this timeline allows for > rigorous final review and activation planning. > > This request isn't meant to suggest that these contributors dictate the > consensus process, but rather it is an acknowledgement that before these > opcodes can be activated, they must be implemented in the most widely > used bitcoin client. > > As application and protocol developers, we are convinced of the > significant benefits that these changes would bring to end users of > bitcoin =E2=80=93 even if only considering their use for layer 1 security= and > layer 2 scaling solutions. We are optimistic that given the limited size > and scope of these changes in both concept and implementation, they > represent a realistic next step in the continuing and important work of > preserving bitcoin's unique promise. > > Signed, > > Abdel (Starkware) > Andrew Poelstra (@apoelstra) > Ben Carman (@benthecarman) > Ben Kaufman (@ben-kaufman) > Brandon Black (@reardencode) > Brian Langel (for Five Bells) > Buck Perley (@puckberley) > Calle (Cashu) > Calvin Kim (@kcalvinalvin) > Chun Wang (f2pool) > Christian Decker (@cdecker) > Coinjoined Chris (Bitsurance.eu) > Evan Kaloudis (for Zeus) > fiatjaf (@fiatjaf) > Floppy (@1440000bytes) > Gary Krause (@average-gary) > Harsha Goli (@arshbot) > Hunter Beast (@cryptoquick) > Jad Mubaslat (@champbronc2) > James O=E2=80=99Beirne (@jamesob) > Jameson Lopp (@jlopp) > Johan Halseth (@halseth) > Luke Childs (@lukechilds) > Matt Black (for Atomic Finance) > Michael Tidwell (@miketwenty1) > Nick Hansen (for Luxor Mining) > Nitesh (@nitesh_btc) > nvk (@nvk) > Owen Kemeys (for Foundation) > Paul Sztorc (@psztorc) > Portland.HODL (for MARA Pool) > Rijndael (@rot13maxi) > Rob Hamilton (@rob1ham) > Robin Linus (@RobinLinus) > Sanket Kanjalkar (@sanket1729) > Sean Ryan (Anchorage) > Seth for Privacy (for Cake Wallet) > Simanta Gautam (Alpen Labs) > Steven Roose (@stevenroose) > stutxo (@stutxo) > Talip (@otaliptus) > mononaut (@mononautical) > vnprc (@vnprc) > > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51be= eb765163n%40googlegroups.com=20 > . --=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/= 035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io. --------------WJMLxOyp006ErkFcX1Uwt80c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey all


I've been following the discussion and noticed TXHASH is mentioned a lot. As a signer of the letter and author of the TXHASH proposal, I'd like to chime in with some thoughts.

However, I'd like to first express my disappointment with the amount of drama this letter has caused. It quite literally merely asks Core contributors to put this proposal on their agenda with some urgency. No threats, no hard words.
Given that only a handful of Core contributors had thus far participated in the conversation on the proposal elsewhere, it seemed like a suitable next step to communicate that we want Core contributors to provide their position within this conversation.
I strongly stand against an approach involving independent activation clients and I think the sentiment of this e-mail aligns with the preference of having Core be involved in any deployment of protocol upgrades.

On the proposal itself. I have heard some mentions of TXHASH and why we, as the developer community, wouldn't go=C2=A0 straight for TXHASH.

  • I think TXHASH is too far from being ready at this point:
    • The TXHASH BIP and spec has not had the level of review/engagement that I had hoped for. I'm personally pretty happy with the result, especially since it only has had serious looks from myself and Rearden. But it definitely needs a lot more scrutiny. It's a very opinionated design (I think it's unavoidable for such an opcode), so there is a lot of room for making different and maybe better decisions on many fronts.
    • Once we have the TXHASH semantics, it would be very valuable to consider also introducing the same semantics as a top-level sighash flag system, so you can spend coins directly with a sighash based on TXHASH semantics. (I dubbed this TXSIGHASH and I recently did some simulations on how such a construction would look for fee sponsoring and stacking http= s://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsor= ring-and-stacking/1760)
    • However, this also invites some additional review of possible taproot changes (pay-to-tapscript, re-adding parity byte, ..) and will necessarily take some more time for consideration and design.
  • I strongly believe it would benefit development of new bitcoin use cases if we would have a simple version of templating and rebindable signatures sooner rather than later. Both BitVM and Ark are fairly recent ideas that stand to benefit significantly from such new functionality, but I think having them actually available will invite a lot more engagement leading to new ideas and new improvements. These are not use case-specific changes, but useful general building blocks.
  • Both CSFS and CTV are fairly unopinionated opcodes by design, when you think of CTV in the sense that it fixes the minimum tx fields to ensure txid stability.
  • I think there is both enough excitement for this proposal and there would be enough future excitement for a TXHASH or CCV addition that I don't fear upgrade churn will be a future hurdle.
  • Even after possible TXHASH activation, I think there will stay some demand for the simpler CTV/TEMPLATEHASH variant. It doesn't just save a byte on the wire, but thinking in a txid-stable model is just more intuitive. I believe that many advanced use cases will take advantage from doing things the TXHASH way (enabling stacking and cheaper fee sponsoring), but some developers will always favor the simplicity of txid stability over the benefits of adding complexity.

The above arguments convinced me that an activation based on CTV and CSFS makes sense today. We have lots of developers waiting to make use of the functionality it enables and we can continue development of further changes meanwhile.

That being said, I'm in no way married to the exact details of the proposals.

  • I am sympathetic to worries of changing legacy/v0 script. I failed to convince myself of any valuable usage for bare CTV.
  • I am sympathetic to the consideration of revisiting scriptSig and annex-related modifications to the template hash.
  • I am sympathetic to the decision to optimize better for the rebindable signature use cases, meaning:
    • the idea to swap CTV for a TEMPLATEHASH opcode which adds a 1-byte VERIFY for the template use case but saves 33 bytes for the signature use case
    • the addition of an INTERNALKEY opcode, saving an additional 33 bytes for the rebindable signature use case
All of the above changes I think can be decided on with minimal bikeshedding and still encompass the same semantics of the original proposal.


Best

Steven


On 6/9/25 12:40, James O'Beirne wrote:
Good morning,

A letter has been published advocating for the final review and
activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK
(BIP-348).

The full text of the letter can be found at https://ctv-csfs.com. It is
reproduced below.

---

To the technical bitcoin community,

We believe that the best next step for bitcoin would be to activate
OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK (CSFS,
BIP-348). These opcodes enable functionality for a broad set of uses
that will allow bitcoin to preserve and expand its role as a scarce,
censorship-resistant store of value.

While there are a few promising proposals to improve bitcoin at the
consensus layer which may someday be deployed, we believe that CTV and
CSFS are uniquely well reviewed, simple, and have been proven to be both
safe and widely demanded.

CTV was first formalized in BIP-119 over 5 years ago. Despite many attempts at refinement or replacement, it has remained the most widely
preferred method for enforcing pregenerated transaction sequences using
consensus. It unlocks valuable functionality for scaling solutions,
vaults, congestion control, non-custodial mining, discreet log
contracts, and more.

CSFS is a primitive opcode that has been deployed to Blockstream=E2= =80=99s
Elements for at least 8 years. It represents no significant
computational burden over bitcoin=E2=80=99s most often used opcode, OP_CHECKSIG.
It can be combined with CTV to implement ln-symmetry, a longstanding
improvement to Lightning. It also unlocks a variety of other use cases.

We respectfully ask Bitcoin Core contributors to prioritize the review
and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or
similar) within the next six months. We believe this timeline allows for
rigorous final review and activation planning.

This request isn't meant to suggest that these contributors dictate the
consensus process, but rather it is an acknowledgement that before these
opcodes can be activated, they must be implemented in the most widely
used bitcoin client.

As application and protocol developers, we are convinced of the
significant benefits that these changes would bring to end users of
bitcoin =E2=80=93 even if only considering their use for layer 1 secu= rity and
layer 2 scaling solutions. We are optimistic that given the limited size
and scope of these changes in both concept and implementation, they
represent a realistic next step in the continuing and important work of
preserving bitcoin's unique promise.

Signed,

Abdel (Starkware)
Andrew Poelstra (@apoelstra)
Ben Carman (@benthecarman)
Ben Kaufman (@ben-kaufman)
Brandon Black (@reardencode)
Brian Langel (for Five Bells)
Buck Perley (@puckberley)
Calle (Cashu)
Calvin Kim (@kcalvinalvin)
Chun Wang (f2pool)
Christian Decker (@cdecker)
Coinjoined Chris (Bitsurance.eu)
Evan Kaloudis (for Zeus)
fiatjaf (@fiatjaf)
Floppy (@1440000bytes)
Gary Krause (@average-gary)
Harsha Goli (@arshbot)
Hunter Beast (@cryptoquick)
Jad Mubaslat (@champbronc2)
James O=E2=80=99Beirne (@jamesob)
Jameson Lopp (@jlopp)
Johan Halseth (@halseth)
Luke Childs (@lukechilds)
Matt Black (for Atomic Finance)
Michael Tidwell (@miketwenty1)
Nick Hansen (for Luxor Mining)
Nitesh (@nitesh_btc)
nvk (@nvk)
Owen Kemeys (for Foundation)
Paul Sztorc (@psztorc)
Portland.HODL (for MARA Pool)
Rijndael (@rot13maxi)
Rob Hamilton (@rob1ham)
Robin Linus (@RobinLinus)
Sanket Kanjalkar (@sanket1729)
Sean Ryan (Anchorage)
Seth for Privacy (for Cake Wallet)
Simanta Gautam (Alpen Labs)
Steven Roose (@stevenroose)
stutxo (@stutxo)
Talip (@otaliptus)
mononaut (@mononautical)
vnprc (@vnprc)

--
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/bitcoind= ev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.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/035f8b= 9c-9711-4edb-9d01-bef4a96320e1%40roose.io.
--------------WJMLxOyp006ErkFcX1Uwt80c--