From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Jun 2025 19:24:12 -0700 Received: from mail-ot1-f58.google.com ([209.85.210.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uPXbv-0000NK-De for bitcoindev@gnusha.org; Wed, 11 Jun 2025 19:24:12 -0700 Received: by mail-ot1-f58.google.com with SMTP id 46e09a7af769-72e2f2b9ea1sf608762a34.3 for ; Wed, 11 Jun 2025 19:24:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749695045; cv=pass; d=google.com; s=arc-20240605; b=MlaZotztXOGT3ICYOoEHJaFrwRLpkJ6fU0izqYUdBEZTAXiYVDVddgc2bclrB7U77j dmJUw9Ga3HYHdI1NTYS0UAHktTHwQK6juIqyfJGusUIwDqnEV23s7+jzH9kOceDVijMp wu7VMREGAB/Rlf5ofn0AWnl98OkY4EmnxNFu2sB4qSfXtfbpzmN/XPCzYVt8h+rA4PQJ Av5oM3mjEhW/1cAbNMAjMKCL1LHYkTgGlvpVhA2gwJTHhrwCJefAI1bphd4Sl2oRiWeN QdT7zqJm3a3OJMGqXdhE6zDW1ejbAIRmI3W6CsSUCEn0wPaDqVFLsGrh5XFzzqGjalez LDKw== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=KFjZnlnVC1wmNhaWb4cI7s6UjimqNVdpcuC+S5DQyn0=; fh=FcWkFfm/rE41sQ7O5yh4EwkAljhp5WxgA9zCFcU5sLY=; b=B4rPU5CcIq5ThHhcW0zSCrvXAMKZi1E3Ee/epDCxXiZQCMg4wOFbGL74uNt6Da61Z5 CyY4fZWO+CjUeTMyDEhfC3bE0Uy5/7qRPKvafilJW/dO2rzFbmSo97mX3gALd9/OJxPk zqujOi60hShGaIlxEM20Fd1wvLbqY7rZrqPdbddAp7a0QNCe6fiCQ876aZit24yLpOrT HBh1bzbDSi3Z7ffEbyycrqMK2s4BmVLZOvMsgClrIJTf7u9p1MzXXtFR+AQGpWLdtYLq inl0uNBVyDp7SN5OTUuDqy2C8Cr/WHKp2WhDRtdOZA9+yoEmUot3Gb1is/44z7Phr4B+ 0jKQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=g65vI7St; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=gmaxwell@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=1749695045; x=1750299845; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=KFjZnlnVC1wmNhaWb4cI7s6UjimqNVdpcuC+S5DQyn0=; b=KjCIKE1xBk7MEQqwbfhN3WOEmj5X1Ebkj70bCN5VVj14Q7QLPZSgG5j7OyPhK68Rna RmtSxzwFn+1s0Y5kSpZ48t32FaJ9KRYwBR2j5E6uJ6GOAVMUS2dgjCDuoX/niXBps81o OlhJwc+VVArIYhDlPmiE47N4W/pRGG4TjFIabt6iw3OLBFUT26E5Xg7+8mtbOvBKQhOj n3wDfHY3N9YX+5MqYhX4EDRcjueTejqe60Tdfn6Xg1lEEf1wO6BQ4dtGds94CLFscWjV qIfzdyY779mvby2Cm1mFq/gPBtyR9KcNOz/KpNGYzNqhGwUG6naBENl8iWjD3awEa55d ldPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749695045; x=1750299845; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KFjZnlnVC1wmNhaWb4cI7s6UjimqNVdpcuC+S5DQyn0=; b=RbuyHyb9j7KUqnxdBh6kct6bUl556cv9U6algvrP5KseCucXR59ehbiwHN2NOi/qrG qGPHcwol/YGdWeok0Scaqn7jG4FvDZOha7NwseM5mwyTGN8Jp5sztAed/LxloyD4MDxr sKDiolTDRGEuk6/DBuSE8y26c3nN4wcYXX28NKRcztet4+pLhkpn4bMploMnI0Z5ZTb5 m+IrkjApiFbMcxZXgpOR3oncQ9TwHOaCXAwU2v6f6YlnhFnBIhm11uEgXCmh/mTz21VS eaHWb7xGT+559irnYz8prw/Uh7ABgjwlgaNcWZzdDlDTVJ20DjHTwo+VYiocL6WVU9y/ 0ofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749695045; x=1750299845; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=KFjZnlnVC1wmNhaWb4cI7s6UjimqNVdpcuC+S5DQyn0=; b=Ky71+khwYbMdixqZbKSugkTdvVG535dDePgNPasQJOaRuPqNEwrDHUuZ4+FdRoKxv/ YILW+prD0ECXHGLw3zMXmnl6KCeOA9g661E90anoVb+42Ih4rdxYSswYMDnEwfVpFm5T vMI/W+nA45JV3dehbDuJmDnE/30obpBtIT5wiImiogc8Ny3uMG8SnTcE3AXNewCnoe/V jSyMYhUhzxSiqyUYpJjTx+8g8q1TlYusxPdPxehZjL87QFLj5pRoOuXyjVWvfU+HBVC2 nqkk3GZTIggSRql1vY2TPppvJwf5PfqZm+U4Q4CEXInZifToS8qLOKRfeSl15IZE5YOg lW9Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCV88p1Ruf+ZBGf2TkeuxWP7TcR16WaCmDrEIJ5gE1yH6Z9YnbdIGghGmK0xmakEWQZAw3MTAtIeQqBO@gnusha.org X-Gm-Message-State: AOJu0YxlcXZNblIgf0OBopRVANS13F8/XMuh/PrwAd6spqlk7PRb2sXv mrosq8FFLYbweodgMXqcR6TtQjI8QWyoWzoTTsbmk+xJeDK1f/EXuECq X-Google-Smtp-Source: AGHT+IHpJx/27vdGW5QjnqBkRyPcNBbciu81olo3MoUKSjfg3StVQhJ2M49QbbtSTRIG9MYtr/XaxA== X-Received: by 2002:a05:6870:7d0d:b0:2d4:edac:d9a9 with SMTP id 586e51a60fabf-2eab6f6990emr725653fac.10.1749695045177; Wed, 11 Jun 2025 19:24:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfpD8reVFC86my33zGd5+Y6GIYTd5tY81PTjrjFvDQbDg== Received: by 2002:a05:6871:68c:b0:2da:b91c:91bd with SMTP id 586e51a60fabf-2eab6ee08a7ls284367fac.1.-pod-prod-09-us; Wed, 11 Jun 2025 19:24:00 -0700 (PDT) X-Received: by 2002:a05:6808:5086:b0:403:5150:c351 with SMTP id 5614622812f47-40a669bff98mr928130b6e.6.1749695040675; Wed, 11 Jun 2025 19:24:00 -0700 (PDT) Received: by 2002:a05:6808:114:b0:403:484c:9068 with SMTP id 5614622812f47-40a5d452f7emsb6e; Wed, 11 Jun 2025 19:07:09 -0700 (PDT) X-Received: by 2002:a05:6a20:3d86:b0:21f:86de:354 with SMTP id adf61e73a8af0-21f9b8c112dmr1538666637.26.1749694027833; Wed, 11 Jun 2025 19:07:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749694027; cv=none; d=google.com; s=arc-20240605; b=WQvZRYfduwFi7oBlFmzsmZNhGHaUoWM0+NQgo4sLWfkGx9TOuUEMfIN+qCBIvoM38Y xMzYw61hPRYqVa3OU2FoquwnenJV65k5Fka2s4OfCwu5aWsUcnanMRZKxubdDCanfhei tsOqoIC6nZ9to7I8VMudEIasbnY740oGsI8pUANbj5H5pqvylo0z1eWhbKNYqoYyzD91 V+CFWcnxSyBQuYSnJqQ1654g9/j5FjLNPZmgLFTe0JoxDKiKQOQvuMCbiy7MrNwbJVWl feB+oAONHJyCUcvX/z4PiOWuKYYDnaldwN3pqye0AhkxEmXtlNbqO6LmGeL09XOXKebV 0uDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JThqlD0Bodk9epTn4oxe4YforDLYqmB4McUiltB2dHY=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=lBMh4Ave/N0+eFK8bHarhHHvO5+7r9B6oVKGbVNo4KT8wtRxxE1iW/68IKxHsG9FmU Ev7rOR3K/6IPIsxRZQWfDzJJX5NhqZ+0kJDf7hxMV1hN8mB7q5dAy30pE+Gzj1PWgWRE 6W6IBkUpPe76XYY7aB2DN+i1XivH+wo3Sttsd3FpOYnSNYv1kiBuaZylOiU6b8mGbFnU r9P2W9KT2TntumZsBDQTHdLwPYH9Dw/TSnRiQXj1CIGou+XtaLXMgiVzz/HXxJx9Pcjg VtmN0TRoPNdwzmTdzzKDrFgV2dHqUCu39vWohqKiQe6+Sh3Vow1OWAtCs0ylS9/IVXVE HXCw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=g65vI7St; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com. [2607:f8b0:4864:20::52f]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-b2fd623b5c5si6373a12.5.2025.06.11.19.07.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Jun 2025 19:07:07 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) client-ip=2607:f8b0:4864:20::52f; Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-b2f603b0ef6so239632a12.1 for ; Wed, 11 Jun 2025 19:07:07 -0700 (PDT) X-Gm-Gg: ASbGnctR3fS8V5wvCtHxhLh+YxjL0RPkjSSnrgdXRZKlvNBusqOJEUNMTHueX91FXF3 K5ag7du0kCog+ExWRqE/vgg/dLHYnzUOAhN92PC0ZADi6ep/PpkcPNvsCBurVkT+XNtjmQYO4Zu WuqF1jiOrP3Ks9gpPymbGBZELMqJEn92MKtBtC8UjV4d4= X-Received: by 2002:a17:90b:1c08:b0:311:df4b:4b7a with SMTP id 98e67ed59e1d1-313c08c8ef7mr1758948a91.29.1749694026989; Wed, 11 Jun 2025 19:07:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Maxwell Date: Thu, 12 Jun 2025 02:06:52 +0000 X-Gm-Features: AX0GCFtMI7z9LT7qV0BK2df-SjcodOtZ4Nlm9L2hv9x3CKgaHRcqAh_9I9Hp3OA Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000f1c5cc06375662b1" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=g65vI7St; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=gmaxwell@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 (/) --000000000000f1c5cc06375662b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Three days ago I replied[1] to this post with a simple question: What steps have the authors taken to reduce the risks that the proposed protocol changes are free of relevant patent encumbrance? In any case, though it's obviously important to make sure that authors or their employers don't have any troublesome restrictions on the consensus rules, it's just as important that third parties don't have any either and much harder to gain confidence on. For prior consensus changes significant effort went into making sure that they wouldn't create an issue _in consensus rules_ since they're not-optional and it's now clear that it was quite worthwhile-- I can only imagine the climate has gotten worse. I consider a clearance effort to be part of the required engineering for any mandatory to implement consensus rule, since even if *you're* hidden in a cave and immune to infringement litigation many Bitcoin users are not and causing users to get it with lawsuits or fees to use Bitcoin would presumably be a tradeoff that made any change unacceptable. (To be clear, this has always been done previously-- but not with proposals coming from outside the Bitcoin project it sounds like it may have been missed). [1] Aside, Somehow this message seems to have resulted in my google account being suspended and it's taken me days to recover it. I'm told the list mods saw my message but were unable to pass it through to the list. After recovering my account, I observed I had an offlist message from obeirne basically asking what I meant by IPR, correctly inferring I might be asking about patents, and then listing the authors. I replied to it and had google inform me that the sender was blocking me. :-/ On Mon, Jun 9, 2025 at 11:54=E2=80=AFAM 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 > > . > --=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/= CAAS2fgRGmWV8%2BxPEQrE%2BmZq9Q-mWiLwMMOaF07BaAuKxax0QXQ%40mail.gmail.com. --000000000000f1c5cc06375662b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Three days ago I replied[1] to this post with a simpl= e question:=C2=A0 =C2=A0What steps have the authors taken to reduce the ris= ks that the proposed protocol changes are free of relevant patent encumbran= ce?=C2=A0

In any case, though it's obviously important to= make sure that authors or their employers don't have any troublesome r= estrictions on the consensus rules, it's just as important that third p= arties don't have any either and much harder to gain confidence on. For= prior consensus changes significant effort went into making sure that they= wouldn't create an issue _in consensus rules_ since they're not-op= tional and it's now clear that it was quite worthwhile-- I can only ima= gine the climate has gotten worse.

I consider a cl= earance effort to be part of the required engineering for any mandatory to = implement consensus rule,=C2=A0 since even if *you're* hidden in a cave= and immune to infringement litigation many Bitcoin users are not and causi= ng users to get it with lawsuits or fees to use Bitcoin would presumably be= a tradeoff that made any change unacceptable.=C2=A0 (To be clear, this has= always been done previously-- but not with proposals coming from outside t= he Bitcoin project it sounds like it may have been missed).

<= /div>

[1]=C2=A0 Aside,=C2=A0Somehow this message seems t= o have resulted in my=20 google account being suspended and it's taken me days to recover it.=C2= =A0=20 I'm told the list mods saw my message but were unable to pass it throug= h to the list.=C2=A0 After recovering my account, I observed I had an offlis= t=C2=A0message from obeirne=C2=A0basically asking what I meant by IPR, corr= ectly inferring I might be asking about patents, and then listing the autho= rs.=C2=A0 I replied to it and had google inform me that the sender was bloc= king me.=C2=A0 :-/



<= br>




<= br>

On Mon, Jun 9, 2025 at 11:54=E2=80=AFAM Jame= s O'Beirne <james.obeirne= @gmail.com> 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 w= ould be to activate
OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSI= GFROMSTACK (CSFS,
BIP-348). These opcodes enable functionality for a bro= ad set of uses
that will allow bitcoin to preserve and expand its role a= s a scarce,
censorship-resistant store of value.

While there are = a few promising proposals to improve bitcoin at the
consensus layer whic= h may someday be deployed, we believe that CTV and
CSFS are uniquely wel= l reviewed, simple, and have been proven to be both
safe and widely dema= nded.

CTV was first formalized in BIP-119 over 5 years ago. Despite = many
attempts at refinement or replacement, it has remained the most wid= ely
preferred method for enforcing pregenerated transaction sequences us= ing
consensus. It unlocks valuable functionality for scaling solutions,<= br>vaults, congestion control, non-custodial mining, discreet log
contra= cts, 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 si= gnificant
computational burden over bitcoin=E2=80=99s most often used op= code, OP_CHECKSIG.
It can be combined with CTV to implement ln-symmetry,= a longstanding
improvement to Lightning. It also unlocks a variety of o= ther use cases.

We respectfully ask Bitcoin Core contributors to pri= oritize the review
and integration of CTV (PR #31989 or similar) and CSF= S (PR #32247 or
similar) within the next six months. We believe this tim= eline allows for
rigorous final review and activation planning.

T= his request isn't meant to suggest that these contributors dictate the<= br>consensus process, but rather it is an acknowledgement that before these=
opcodes can be activated, they must be implemented in the most widelyused bitcoin client.

As application and protocol developers, we ar= e convinced of the
significant benefits that these changes would bring t= o 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 g= iven the limited size
and scope of these changes in both concept and imp= lementation, 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 (C= ashu)
Calvin Kim (@kcalvinalvin)
Chun Wang (f2pool)
Christian Deck= er (@cdecker)
Coinjoined Chris (Bitsurance.eu)
Evan Kaloudis (for Zeu= s)
fiatjaf (@fiatjaf)
Floppy (@1440000bytes)
Gary Krause (@average= -gary)
Harsha Goli (@arshbot)
Hunter Beast (@cryptoquick)
Jad Muba= slat (@champbronc2)
James O=E2=80=99Beirne (@jamesob)
Jameson Lopp (@= jlopp)
Johan Halseth (@halseth)
Luke Childs (@lukechilds)
Matt Bla= ck (for Atomic Finance)
Michael Tidwell (@miketwenty1)
Nick Hansen (f= or Luxor Mining)
Nitesh (@nitesh_btc)
nvk (@nvk)
Owen Kemeys (for = Foundation)
Paul Sztorc (@psztorc)
Portland.HODL (for MARA Pool)
R= ijndael (@rot13maxi)
Rob Hamilton (@rob1ham)
Robin Linus (@RobinLinus= )
Sanket Kanjalkar (@sanket1729)
Sean Ryan (Anchorage)
Seth for Pr= ivacy (for Cake Wallet)
Simanta Gautam (Alpen Labs)
Steven Roose (@st= evenroose)
stutxo (@stutxo)
Talip (@otaliptus)
mononaut (@mononaut= ical)
vnprc (@vnprc)

--
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.googl= e.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegrou= ps.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/CAAS2fgRGmWV8%2BxPEQrE%2BmZq9Q-mWiLwMMOaF07BaAuKxax0QXQ%= 40mail.gmail.com.
--000000000000f1c5cc06375662b1--