From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Jun 2025 11:57:47 -0700 Received: from mail-qv1-f61.google.com ([209.85.219.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uRbVA-0005L2-Eg for bitcoindev@gnusha.org; Tue, 17 Jun 2025 11:57:46 -0700 Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6fac216872csf118869416d6.2 for ; Tue, 17 Jun 2025 11:57:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750186654; cv=pass; d=google.com; s=arc-20240605; b=Tx9RTfP9LWMSe26GtAwNnlJ1DexRECksDHFBb91HiPKXUVekFaujsGU3zZ3WhCJ2G5 enP+TDi2v+AKqpqx6BF7/PqLb3wk8VHOcvDJ2nmsJLkTUNVVIRQs7K3E2cvCKp8/J5QH 3+zjzw0LRhGNuZNGC+SimSgZOzcgoSZLQtuqPIEUSzYhlRBi9+7K7Kuvsm0zghiIHGaq thPiHH7XBoU8/A2xhTihmXyvH3BCP1NFV63FvLPiA0grjadD16CN4IhijwlzOlyPAtAi SHoP0qHPhkh1qYv6Jni8tISI7HWrBwJOpH8P/sxOPe7RYGZPI2Y6aJTTif0UXwbHeZGu dLeA== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=bdE7EIhYX8rQtD05X+OsQEfgLio8A4fuByxLEHdp514=; fh=Omv9h5QhyVhx+evRUyxApESfnytLQzWQJ08b5CI6Vb0=; b=Ib4FreIMu1UQlUxOM/N8dPQHQ5IORScmBIehP/zxcWAyKrSIXiTGSDA3w7UMM6ObFK etjqnSEnwpgi1+F0FqV8vRpbF+FnmVIf7SYcLquuNpcC1Ow1CmYXbKkw0mGIX8U1/IF9 BMJguF3xf8WYND8zSqgKankZ1WaeiEOsnRRLO8P25KfnwYZzSBgveZQdHJHKyuXrB0Mw c0FBsGc82eMg5qI/KPhonjScCDuRT3hT6fxNADPYhr2gWKbmk4g4BXmP2T4UKqtWL8Cj jGfis5z3Vro5xLfeVZc6NhXYo04bBZBWhV2QIPg87FyAfDRJte56plTWPnBVebJcp5Wk 42dQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hVPeV0eK; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750186654; x=1750791454; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=bdE7EIhYX8rQtD05X+OsQEfgLio8A4fuByxLEHdp514=; b=wwP68SE2JSa9cxlQTTSDLkE4sJ5mP96HXSEpghAhAk1J1S0CmL0ErcM+/PlcMYClsD 3wEy6DN85Hc500/SJDX7SJpLxnKG5iCEKgTOggn0qAD/pbdVnqAnkk09WQqRKvDyXxw6 F7UD65FHtPLixtd5kUiiZwRAyJFqh78EvtNMggNIgk1VGm9l/PPvWLw2YDpgnOMZBWM7 EGriaqk8pT9ysVATW7qHG8j70XeUsjso4tJbf1TEFUI+ZjeNo3+aiOR6i80WzPASrZPF f5S5AEPw/Xx1kdm4tgWzWKqrzcBbGn058fFq0I6OuDjipuA9FpKRQuu6Whz5UOjRqscQ D67Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750186654; x=1750791454; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bdE7EIhYX8rQtD05X+OsQEfgLio8A4fuByxLEHdp514=; b=KCJREcduHIGSWbMD7YVWbav16lNSWFr17jzwJofopchimD/uRHvOltOScGZt9ykYcI /mcVDNRbI4Ouo+W4k4wTEqr+uyfoWIN1X6gwyAjP/PlzWXwYcamW5iyT1bVdl/8PA7wE 87l24GOuqcVdeaDOTmtFiwWTkqIrFICFUaGo4aHr1SqWDyekMAEjSjHlgWs57VhP2Fpe KEWClP1m9/sHb3yJu/nOIF8DDFb1enfSKiozNBaeU9TZyiB/z4pEitmyxBm01BInSiyA sNdDDwlX/mw2IZARHGSySmZd+ykMY2dS7BBCxkpKDFSQyNzsSsgja8g1J2Hqo0apkw1e 2HAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750186654; x=1750791454; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=bdE7EIhYX8rQtD05X+OsQEfgLio8A4fuByxLEHdp514=; b=nXrgZprKYYrc0QEWfHc8yDo8+aKt31Dihb7GQCZ15mrLfuK9MuVs3vxCcGOiGQoC1E EXaxkAXeq/hgDlV6A1b7P+pHezDH05G8LE/U0xhWIhU6mETrp7JhjPafPSNAKqMcs8yz KN61Fi+U6udJqOIfiFZLCZ+VxP3HeuBxv031Jq5aMwT52C0ZxH6MV4i7IQhMY7s+s8i1 T6mL00wsg6CxJntMefIsZstsoX/1CYJzuXiqimx2UxaCtrCn13J/HDDLzNDuuugJvDDY hYj8Idoqcc8A7SSBKcNttHJ3PN7Mkj5i4l/68C9QtbmykFU/1JRYfcjy96LUbXdriki6 XTbw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWHpVpKLzzwBBcxmJmpqFtbhuams5bqU4UBM/7zcJZu0KYHuhmSYUQ3Y5d0cehQ6n5CsPv46MJaHNW2@gnusha.org X-Gm-Message-State: AOJu0Yx6Pf3QsQ3Qa0gPzrFld+e5x311wmz98q+O5AMZEjFkJjvb6YTe 5kRrG2Z1po3dr6q2CDVTgXfByMIT4V2cdC+3VRbOL7qsWtC8oJOd0/vZ X-Google-Smtp-Source: AGHT+IFr6vzsgI8SXrVaiMFEOl7jgLbrOHl9EKmIVLmBGt7nwNdQZ6YGpnDR0f99NvsvPZpp3+d9vQ== X-Received: by 2002:a05:6214:5f07:b0:6fa:9a6a:7d03 with SMTP id 6a1803df08f44-6fb47773412mr284781886d6.7.1750186654460; Tue, 17 Jun 2025 11:57:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf6HaT4zQIYGUnUTiEkOQehfse+n+XRdyY1ltH2v4g4bQ== Received: by 2002:a05:6214:250c:b0:6fa:bf2a:9be7 with SMTP id 6a1803df08f44-6fb3544c20fls80996526d6.0.-pod-prod-06-us; Tue, 17 Jun 2025 11:57:30 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXLGlUMWrP5ka18x9vkvgaZXe8NFQCiFzbXwiUfutqKDItYxLxiFgFnrAHnc25sPiBGozE78OtbQsIT@googlegroups.com X-Received: by 2002:a05:6214:1242:b0:6f4:cfb3:9df9 with SMTP id 6a1803df08f44-6fb477e7e2cmr246092416d6.33.1750186650060; Tue, 17 Jun 2025 11:57:30 -0700 (PDT) Received: by 2002:a05:620a:5d8e:b0:7c5:3b15:3956 with SMTP id af79cd13be357-7d3e0088b54ms85a; Tue, 17 Jun 2025 11:20:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXVNq3BppcIXMwNqQ8LyQgFb4NrtoWL6sXm9BBnUmoKOgpYNh6/V6EubaoJI0a93AXeaPGtE1uoTsKM@googlegroups.com X-Received: by 2002:a05:6102:38c7:b0:4e5:a0a9:3ad1 with SMTP id ada2fe7eead31-4e7f618872fmr11862663137.2.1750184404355; Tue, 17 Jun 2025 11:20:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750184404; cv=none; d=google.com; s=arc-20240605; b=fUYA0y446P6ga5t3mNya4PIx66qIaLOHuOKKHXdwYIwNQ2DU9FTFx1mraDFOI/rVmx Wy2yaZ+XpQwW2Ip/qQ2U8alVOUlPpZYnkVvwgrrPb792BBrOsKP+u5TsKVd/qIy727ey d3LZxjOMJGGxWSIdkcohm32jAlHWKgBxhtlufFNx5xq6+xy9QeIKA9aj3PBCJBtN1hwj n/4oO/Yt34ALkQCCeqmMrcQSDcf4Dc8PMW3oKh+uwII//T1fYg7UAVUjWS2OxtK9NBi2 XeIrAj3R/R6q+kKOaKe5wzxWxT2aVuz/mGCo7w8+YliJynSCpgyXpmWbGoaBLO7mD9B0 Hpzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=i/03a/iN4wX7ONqkpTQOTNRV9dLqDA8Y4JhCydMVsK4=; fh=Qb7Th88gVgsldXA/DvCLgkkwdjUd69ItlBX/JkXucLs=; b=ioaduLFUU9kgPBExc6kAGvI4wT445h7qEzFLQWXkZN8uoKQ5e0JWdCOMwDIlUJ8Fnd WSHnw7GNKmyaxobYnOkpFiHJ7BEHIQzjw+tktF5tGtf5IVoZMFUIqLRgFpEg6KJdAwiU WIt42x+EVQ2hyM+9veLtEqxjQh/thNQbGrFE3FCP3nZhjctn0qCEuFAUtT6gChOmg7nE QIyGtSubo1Bu1LwtMTE220Air7uNhM7pK4DVvz0QQ7H24ujLe3RSCPdagmZFET5u4e6O 1dFOYlXSalzjlF92N80LF/1XIC7d/Xpq7+MKKe8eMTbHVh78XRlEeWEsAxIKCNsn1kGc jH+A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hVPeV0eK; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com. [2607:f8b0:4864:20::329]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-87f0f9f384fsi382684241.1.2025.06.17.11.20.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jun 2025 11:20:04 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) client-ip=2607:f8b0:4864:20::329; Received: by mail-ot1-x329.google.com with SMTP id 46e09a7af769-72c13802133so2176795a34.3 for ; Tue, 17 Jun 2025 11:20:04 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXHGZL9aBBL6otRGrFKFPlgm/Ly/SEX2P2jUYwPOEexWZs/WevQidTPqKDE34K+US5WmVdzLHmLGJoo@googlegroups.com X-Gm-Gg: ASbGncsvsZeGALA+zhUf9nsqfQ0RYCK6vW9wginh3LRoKKVIwQu30lPAhLG70T9lzFw cls/bWse1pakR0P5V3M360a86/6pjN4ES598xmsEhG9GZs3ufpTdNz9tgmM+8FF1XtTGl8JYC10 lSRI+hMVlVHbKMTaoNI9Mc9QBI1BLfhiKAxRiAUfB++l4j9szRiMwmAi/kozyX1fSTov0zZ7GH X-Received: by 2002:a05:6870:d251:b0:2e9:365:d0d3 with SMTP id 586e51a60fabf-2eaf083722cmr7977190fac.21.1750184402607; Tue, 17 Jun 2025 11:20:02 -0700 (PDT) MIME-Version: 1.0 References: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io> In-Reply-To: From: "/dev /fd0" Date: Tue, 17 Jun 2025 23:49:50 +0530 X-Gm-Features: Ac12FXzzsDgrtBEXxbvq-Nh82gV3-MneCH2erF2cwXFyKByoA04QkNDQX42ea2A Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Antoine Poinsot Cc: Steven Roose , "James O'Beirne" , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000009be4ec0637c88fd7" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=hVPeV0eK; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --0000000000009be4ec0637c88fd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I created a wiki page for [use cases][0] in December 2024. It does not include LN SYMMETRY and other things possible when CHECKSIGFROMSTACK is used in combination with CHECKTEMPLATEVERIFY. I don't think there's anything wrong with the language used in the letter or the intentions of those who signed it. The misinterpretation may be genuine or simply an excuse to stall the process for a few more years. That said, I had suggested [rephrasing][1] one of the paragraphs to help avoid misunderstanding and keep the focus on technical discussion. I really appreciate James O'Beirne for his efforts, as well as the others who signed this letter. Most users prefer public communication about soft forks. [0]: https://en.bitcoin.it/wiki/Covenants_Uses [1]: https://github.com/ctv-csfs/ctv-csfs.github.io/issues/15 /dev/fd0 floppy disk guy On Tue, Jun 17, 2025 at 9:03=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel= opment Mailing List wrote: > Steven, > > I'd like to first express my disappointment with the amount of drama this > letter has caused. > > > Likewise. As i mentioned earlier i think this bundle of capabilities is > worth considering for a use case driven soft fork. I felt like, despite t= he > lack of substantive work on the proposal, we were finally going somewhere > in the discussion on extending Bitcoin's scripting capabilities. > > Instead of addressing minor objections to the design of the operations an= d > working on demonstrating (real) use cases, the champion chose the route o= f > political pressure on the Bitcoin Core project. Signatories backed this > approach. > > In changing Bitcoin, the process matters as much as the outcome. If > Bitcoin can be changed through a shouting match and on the basis of > misleading pseudo use cases, it would be a major fuck up. Likewise if a > suboptimal change can be rammed through without addressing objections and > reasonable requests from the technical community, by bamboozling industry > stakeholders into the false dichotomy "it's either this or ossification". > > Bitcoin Core cannot, in my opinion, facilitate setting such a precedent. > Therefore this effort sets us back a long way in getting a consensus chan= ge > merged there, and on the broader path of extending Bitcoin's scripting > functionalities > > It quite literally merely asks Core contributors to put this proposal on > their agenda with some urgency. > > > This is incorrect and misrepresenting the content of the letter. It > specifically asks, i'm quoting "integration of CTV (PR #31989 > or similar)". This is > asking Core to merge a pull request implementing a contentious consensus > change. And so, not by making the case for it with strong technical > arguments but by presenting signatures from industry stakeholders. I trus= t > we all both agree it is inadvisable to change the Bitcoin Core decision > process from making software changes based on objective rough technical > consensus toward making software changes based on the subjective intentio= ns > of whoever has influence in the space at the moment. > > Given that only a handful of Core contributors had thus far participated > in the conversation on the proposal elsewhere > > > And pressure to merge code for an obviously controversial consensus chang= e > is a great way to make sure not more of them engage, if lurking at how pr= evious > CTV discussions went > > wasn't enough. > > it seemed like a suitable next step to communicate that we want Core > contributors to provide their position within this conversation > > > How could you ever think it be a "suitable next step"? Bitcoin Core > contributors spend their days maintaining the existing Bitcoin network, > where making it boringly stable is success. Asking the project to merge a > contentious consensus change, disregarding conceptual review, is just > laughable. I don't see how piling a sign-on letter on top of this would > improve anything. > > In conclusion, i would like to state i understand the frustration of this > proposal not making progress and how it led many signatories to get on > board with the letter. I do not ascribe bad intentions to most of them. > However the effect of this letter has been, as could have been expected, = a > major setback in making progress on this proposal (or more broadly this > bundle of capabilities). I am not sure how we bounce back from this, but = it > necessarily involves someone standing up and actually doing the work of > addressing technical feedback from the community and demonstrating (real) > use cases. The way forward must be by building consensus on the basis of > strong objective, technical, arguments. Not with a bunch of people statin= g > interest and nobody acting up and helping the proposal move forward. > > Best, > Antoine Poinsot > On Tuesday, June 17th, 2025 at 7:31 AM, Steven Roose > wrote: > > 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 preferen= ce > 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 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 Rear= den. But > it definitely needs a lot more scrutiny. It's a very opinionated de= sign (I > think it's unavoidable for such an opcode), so there is a lot of ro= om 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 TXH= ASH > semantics. (I dubbed this TXSIGHASH and I recently did some simulat= ions 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 > ) > - However, this also invites some additional review of possible > taproot changes (pay-to-tapscript, re-adding parity byte, ..) and w= ill > 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 rebindab= le > signatures sooner rather than later. Both BitVM and Ark are fairly rec= ent > ideas that stand to benefit significantly from such new functionality,= but > I think having them actually available will invite a lot more engageme= nt > leading to new ideas and new improvements. These are not use case-spec= ific > 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 e= nsure > 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 sponsor= ing), > 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 chang= es > 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 signatu= re 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=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) > > -- > 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/a86c2737-db79-4f54-9c1d-51be= eb765163n%40googlegroups.com > . > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/035f8b9c-9711-4edb-9d01-bef4= a96320e1%40roose.io > . > > > -- > 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/GLGZ3rEDfqaW8jAfIA6ac78uQzjE= dYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9= U7Y4%3D%40protonmail.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/= CALiT-Zr3KO0fw1_DCpDVvA1Z1aLrvM-HFtvdsyLKhXxWvR%3DhvA%40mail.gmail.com. --0000000000009be4ec0637c88fd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I created a wiki page for [use cases][0] in December 2024.= It does not include=C2=A0LN SYMMETRY and other things possible when CHECKS= IGFROMSTACK is used in combination with CHECKTEMPLATEVERIFY.

=
I don't think there's anything wrong with the language used in= the letter or the intentions of those who signed it. The misinterpretation= may be genuine or simply an excuse to stall the process for a few more yea= rs.=C2=A0That said, I had suggested [rephrasing][1] one of the paragraphs t= o help avoid misunderstanding and keep the focus on technical discussion.
I really appreciate James O'Beirne for his efforts, as well as th= e others who signed this letter. Most users prefer public communication abo= ut soft forks.


On Tue, Jun 17, 2025 at 9= :03=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Development Mailing Li= st <bitcoindev@googlegrou= ps.com> wrote:
Steven,

I'd like to first express my di= sappointment with the amount of drama this letter has caused.
=20
=20
=20

Likewise. As i mention= ed earlier i think this bundle of capabilities is worth considering for a u= se case driven soft fork. I felt like, despite the lack of substantive work= on the proposal, we were finally going somewhere in the discussion on exte= nding Bitcoin's scripting capabilities.

Instead of addressing minor objections to the de= sign of the operations and working on demonstrating (real) use cases, the c= hampion chose the route of political pressure on the Bitcoin Core project. = Signatories backed this approach.

In changing Bitcoin, the process = matters as much as the outcome. If Bitcoin can be changed through a shoutin= g match and on the basis of misleading pseudo use cases, it would be a majo= r fuck up. Likewise if a suboptimal change can be rammed through without ad= dressing objections and reasonable requests from the technical community, b= y bamboozling industry stakeholders into the false dichotomy "it's= either this or ossification".

Bitcoin Core c= annot, in my opinion, facilitate setting such a precedent. Therefore this e= ffort sets us back a long way in getting a consensus change merged there, a= nd on the broader path of extending Bitcoin's scripting functionalities=

It quite literally merely asks Core contributors to put this proposal on their agenda with some urgency.

This is incorrect= and misrepresenting the content of the letter. It specifically asks, i'= ;m quoting "integration of CTV (PR #31989 or similar)". This= is asking Core to merge a pull request implementing a contentious consensu= s change. And so, not by making the case for it with strong technical argum= ents but by presenting signatures from industry stakeholders. I trust we all both agree it is inadvisable to change the Bitcoin Core = decision process from making software changes based on objective rough tech= nical consensus toward making software changes based on the subjective inte= ntions of whoever has influence in the space at the moment.

Given that only a handful of Core contrib= utors had thus far participated in the conversation on the proposal elsewhe= re

And pressure to merge code for an obvi= ously controversial consensus change is a great way to make sure not more o= f them engage, if lurking at how prev= ious CTV discussions went wasn't enough.

it seemed like a suitable next step to communicate that we want Core contributors to provide their position within this conversation

How could you ever think it be a "suitable next = step"? Bitcoin Core contributors spend their days maintaining the exis= ting Bitcoin network, where making it boringly stable is success. Asking t= he project to merge a contentious consensus change, disregarding conceptual= review, is just laughable. I don't see how piling a sign-on letter on = top of this would improve anything.

In conclusion, i would like t= o state i understand the frustration of this proposal not making progress a= nd how it led many signatories to get on board with the letter. I do not as= cribe bad intentions to most of them. However the effect of this letter has= been, as could have been expected, a major setback in making progress on t= his proposal (or more broadly this bundle of capabilities). I am not sure h= ow we bounce back from this, but it necessarily involves someone standing u= p and actually doing the work of addressing technical feedback=20 from the community and demonstrating (real) use cases. The way forward must= be by building consensus on the basis of strong objective, technical, argu= ments. Not with a bunch of people stating interest and nobody acting up and= helping the proposal move forward.

Best,
Antoine Poinsot<= br>
On Tuesday, June 17th, 2025 at 7:31 AM, Steven Roose <steven@roose.io> wrote:
=20

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 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 https://delvingbitcoin.org/t/jit-fees-with-txhash-compar= ing-options-for-sponsorring-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:
=20 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+un= subscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegrou= ps.com.
=20

--
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 bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0= wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com<= /a>.

--
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/CALiT-Zr3KO0fw1_DCpDVvA1Z1aLrvM-HFtvdsyLKhXxWvR%3DhvA%40ma= il.gmail.com.
--0000000000009be4ec0637c88fd7--