path: root/e2/2231a552a39da5564a6c49fbdc4694557a60af

Delivery-date: Tue, 17 Jun 2025 08:33:14 -0700
Received: from mail-oi1-f186.google.com ([209.85.167.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBLUVY3BAMGQEZ5NWIJQ@googlegroups.com>)
	id 1uRYJE-00057W-Ap
	for bitcoindev@gnusha.org; Tue, 17 Jun 2025 08:33:14 -0700
Received: by mail-oi1-f186.google.com with SMTP id 5614622812f47-40a55d8135dsf1853094b6e.2
        for <bitcoindev@gnusha.org>; Tue, 17 Jun 2025 08:33:12 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750174386; cv=pass;
        d=google.com; s=arc-20240605;
        b=a6RLWi9P0iMYY8ukFTsjHkgeUltOhrDNfBYT9C9Zgv7joKtHU5B7fGX7VxZPvDytf4
         IXAxqyvWbWxSUly506VM3/tNnbnGb+1X55Bmv/Vrz6B6C+ttywdzj/vCtwjGWqJKC+Tw
         UQoeYmhzl3TuaUXI0gXpGzOZhVXsgnY68oMmFiESmX51tL1bDm3WQk7mxy4PQlLeEj0x
         Es0vMSHX5krRB7EO3Jxzz8uOrJ1GqHFLAs/YJqUtHnBaXlXSeqckl0YK+vHub9E1QqDi
         USh+AUTtWmvPBEseZ5uRJXfY9dqMIyX9GfFa1jm+v0sXMMrkJz+qP3CLmGFRgqFiKGgx
         /86g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=GET3i5hh5zIBFoqyHFJ5w8ToGUSN3y4idifFOPrTiWU=;
        fh=QAWF7CHcAKNWb2S64l0a5qntfw2wjzii1Inpzdvr49I=;
        b=hvCwGW4z5J9Z9So4LDJl9BFa9fl2m3wMWAKHeFbaBN7+Z+IUCUYLhoU2SFaQBEF2zr
         ZTrgBIt3o1rTb18xHQlrfHGOKoKm6c/eVmO+/BOaSmfeF64WAgmiXXPTRbKHCzl74RiK
         1i0Pk+q8c0e2M9/FH60BhLtqPbkNyUGXMfduIGnPZv+bLtohd/Y9xJf53kbojxk1nKPv
         aFgFtdgvbo6WT2w9aYdLEa6ci5ZQzwZWVuexByMsSCuUpL0EnpyhXibXP1aOP8gs9PBE
         pTfLBeWnLvSfnpSfDr/qiobaCDKaEfDuC54JcF8VGHe1++PTwFmMKtJEoI2gfOB5tA7X
         GftQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=wsMl1vUR;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750174386; x=1750779186; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=GET3i5hh5zIBFoqyHFJ5w8ToGUSN3y4idifFOPrTiWU=;
        b=nykK1yN4aKXepahBZXCxOcJhikKtpfiHrmMVU0g5L3WJPYKVSxn+0W1JWszhTaDYys
         KFQVGTiBZcKp7yFN1wzIvLmhdc5mHnB8BcqQEIi+PmMx8CdwIUnc+T1aaHPY1S1DSHBa
         IuhDfv5q79bCRDdFpbTkhrtMDnmQUuZY1Cij+0Ta0KADVVo+lypDiDjzHw8mRKJ4/0i1
         TNhy9SvKDG8zYip2sYgFwnXmcAB35nDnVxcy55RPfzfCr3gqVgZ/485gZvwuVfl97wsK
         i1acG+pf5+WiMDnuvHpnNbnlsx2MmVaQULgMfO+Lqp1RWsDc2UR1jGVStfya9uI79IRw
         bhIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750174386; x=1750779186;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GET3i5hh5zIBFoqyHFJ5w8ToGUSN3y4idifFOPrTiWU=;
        b=Ii1+cyxrzNE+bYOv5RGFxuK6dZskO2aNidzFO4E6YydNCtIgrfVG0THXQFxFk5pk9E
         hCrTNNbMWIXOobCFtzMhS7XPAEd08zkUbGKwXBVxSsT2o9qf+bfgVuLG/4t0RWNNMOT7
         ssU1bF5UtjF2QlMcDkUsGifgwTQMMRLsP25oYrnhdtIGn6tUsCVTIGrJIMf7SKuYi6u7
         Iq0Ja9xQSf4dUhgOYYSA+AVk+Tkh+WXt+fYuTE3bbs1JzuObUYmbun+BMAw03OVBHeJD
         P1oNffOGuNpWZI0366xYTLrmWqVygU6L8tS7WA5q0VW47GPZMPVOPJOjjZaa4C3pBIVF
         Mp6g==
X-Forwarded-Encrypted: i=2; AJvYcCVnCSKpYJEgbO6BtgcGcx17GrxFmcMYjNtsFw8TgPRKxaVYUHdDW2yNSQ4FCUWtIf1BwdBXC2sagUP7@gnusha.org
X-Gm-Message-State: AOJu0YwvyWjO8/LH9EDCfE9OBkBIl3i8GFhQVIRKwpLtGpxygoxiU+Tp
	zzzpWLRpWBhyQGtwx2ec+AoHnAwjBqSiHiKeUBBi0YwUTh+p48Mxiu55
X-Google-Smtp-Source: AGHT+IG1Z//vkh1XGIrC7JAgVVVPfHnVK8Ag97XEyYk2HR5HCWthpuhLWqLLtemhXMAo1la50o9dwg==
X-Received: by 2002:a05:6808:7047:b0:401:ea99:54b with SMTP id 5614622812f47-40a7c178170mr6146696b6e.23.1750174386275;
        Tue, 17 Jun 2025 08:33:06 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfAIoW93zPVUhqijg30tjp5JKkWVZeMbEBrx5CNAV6qYQ==
Received: by 2002:a05:6820:770e:b0:611:3bba:29d8 with SMTP id
 006d021491bc7-6113bba2af4ls104361eaf.0.-pod-prod-06-us; Tue, 17 Jun 2025
 08:33:02 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCU06oYgdrNzhpvWG4yeApG88BxHgkGHzpulh13BJM3dI94C6FgE/LUaC6kSqMOov2QtKN+Lon0Jsqgu@googlegroups.com
X-Received: by 2002:a05:6808:17aa:b0:3f9:aeb6:6eac with SMTP id 5614622812f47-40a7c18b1e6mr8614109b6e.30.1750174382243;
        Tue, 17 Jun 2025 08:33:02 -0700 (PDT)
Received: by 2002:ab3:5f96:0:b0:2b1:9db7:3101 with SMTP id a1c4a302cd1d6-2b53168773cmsc7a;
        Tue, 17 Jun 2025 07:34:47 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCU/Xk47UuRlOUJUlnJeGhfq0TKvGa7LrrHlDmQrzS6Qi3P2Sr5mCsZxyNLgry325nfyLxhYjWWKFKIE@googlegroups.com
X-Received: by 2002:a2e:be24:0:b0:32a:8c7a:8332 with SMTP id 38308e7fff4ca-32b4a5c4ed1mr50391881fa.28.1750170882554;
        Tue, 17 Jun 2025 07:34:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1750170882; cv=none;
        d=google.com; s=arc-20240605;
        b=Iu1A7/b8jVaT83KsiouDG26avCaftGuPtYp45sXNsw03aP40LJCm7L9atFXOMcRYLf
         NrDDaq8FXwuaVEo6A8ZeFslPjltqYllax3/3jMGKFukakiyFn0Zo9yOsKRc+doXd9KUM
         HSpndCWORVzdNInyr3jZYj0yszHVkwzHL0PMIaEp9GPd93HfKfOizxIyLHFh/+SRpAmS
         H7/aaY7aqkDdFS5wuybKk+80TgHx/mI77VPbhs+v4FAANr0GFwjRYi+khNQg20PNmKLz
         oCiivs3HwTdVM8g4TXSdMKrQDicEHRz03dcD0zBtji6DASpc72KMjmNqsBbw6l19Mr6E
         PW+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=mk+crok2BX5ZyG6ckFrd5wsgbP/lAH53V4dzHRGL22w=;
        fh=MV1nSf9Pbb9SVXfpklmihM2sgFGaaUkNGBJw7XTr2II=;
        b=iwewtpTG6lNhLvYDXinEm+qmRDpyVBeW89Tu0Io6vR95LxzO+qz53FFr4h7w7FQ0hr
         R8oc6zvzLT84MWqVnHy1t+09Vc3o0QOG/aufo6ZH/M9QaT0J+JqOM925WZJbBc4nq614
         qmrzosh/I+k6VWJa0t3Ni/gWdfeYMjbEOe2knmbWeCYbW+P6/jjhBNYf5lFEsXTWtgBH
         U7gTzMbIT6igLS/1bLdOpqc2s0iPS/40UqcrDZQbZYJ6/ZLlC28J7iA1huyme+PalPKc
         GzVpWTRZEVN2RJGM0hIZFg6nLjlL0Umpjrnh6EH99gHrzXtK2sV7WqY2SntuZ+d/5FWA
         doXw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=wsMl1vUR;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-32b3310b8d2si3348781fa.8.2025.06.17.07.34.42
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 17 Jun 2025 07:34:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Tue, 17 Jun 2025 14:34:35 +0000
To: Steven Roose <steven@roose.io>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: James O'Beirne <james.obeirne@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Message-ID: <GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4=@protonmail.com>
In-Reply-To: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com> <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: fbd55681cd5dfcbdcba52fe12a27b6a77314b6a2
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_LA1QV1HCVrFyMFi0XHZu8CQLMKFmbjV7s4C5aGxog"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=wsMl1vUR;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

--b1=_LA1QV1HCVrFyMFi0XHZu8CQLMKFmbjV7s4C5aGxog
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 wor=
th considering for a use case driven soft fork. I felt like, despite the la=
ck 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 and =
working on demonstrating (real) use cases, the champion chose the route of =
political pressure on the Bitcoin Core project. Signatories backed this app=
roach.

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 pse=
udo use cases, it would be a major fuck up. Likewise if a suboptimal change=
 can be rammed through without addressing objections and reasonable request=
s from the technical community, by bamboozling industry stakeholders into t=
he false dichotomy "it's either this or ossification".

Bitcoin Core cannot, in my opinion, facilitate setting such a precedent. Th=
erefore this effort sets us back a long way in getting a consensus change m=
erged there, and on the broader path of extending Bitcoin's scripting funct=
ionalities

> 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 specifi=
cally asks, i'm quoting "integration of CTV (PR [#31989](https://github.com=
/bitcoin/bitcoin/pull/31989) or similar)". This is asking Core to merge a p=
ull request implementing a contentious consensus change. And so, not by mak=
ing the case for it with strong technical arguments but by presenting signa=
tures from industry stakeholders. I trust we all both agree it is inadvisab=
le to change the Bitcoin Core decision process from making software changes=
 based on objective rough technical consensus toward making software change=
s based on the subjective intentions 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 change =
is a great way to make sure not more of them engage, if lurking at how [pre=
vious CTV discussions went](https://delvingbitcoin.org/t/ctv-csfs-can-we-re=
ach-consensus-on-a-first-step-towards-covenants/1509/37?u=3Dantoinep) wasn'=
t enough.

> it seemed like a suitable next step to communicate that we want Core cont=
ributors to provide their position within this conversation

How could you ever think it be a "suitable next step"? Bitcoin Core contrib=
utors spend their days maintaining the existing Bitcoin network, where maki=
ng 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 p=
roposal 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 se=
tback in making progress on this proposal (or more broadly this bundle of c=
apabilities). I am not sure how we bounce back from this, but it necessaril=
y involves someone standing up and actually doing the work of addressing te=
chnical 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 stating interest and nob=
ody acting up and helping the proposal move forward.

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

> 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 c=
hime in with some thoughts.
>
> However, I'd like to first express my disappointment with the amount of d=
rama this letter has caused. It quite literally merely asks Core contributo=
rs to put this proposal on their agenda with some urgency. No threats, no h=
ard 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 ne=
xt step to communicate that we want Core contributors to provide their posi=
tion within this conversation.
> I strongly stand against an approach involving independent activation cli=
ents 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 s=
ince it only has had serious looks from myself and Rearden. But it definite=
ly 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 diffe=
rent and maybe better decisions on many fronts.
> - Once we have the TXHASH semantics, it would be very valuable to conside=
r also introducing the same semantics as a top-level sighash flag system, s=
o 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 co=
nstruction would look for fee sponsoring and stacking https://delvingbitcoi=
n.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking=
/1760)
> - However, this also invites some additional review of possible taproot c=
hanges (pay-to-tapscript, re-adding parity byte, ..) and will necessarily t=
ake some more time for consideration and design.
> - I strongly believe it would benefit development of new bitcoin use case=
s 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 hav=
ing them actually available will invite a lot more engagement leading to ne=
w 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 txi=
d stability.
> - I think there is both enough excitement for this proposal and there wou=
ld be enough future excitement for a TXHASH or CCV addition that I don't fe=
ar upgrade churn will be a future hurdle.
> - Even after possible TXHASH activation, I think there will stay some dem=
and for the simpler CTV/TEMPLATEHASH variant. It doesn't just save a byte o=
n the wire, but thinking in a txid-stable model is just more intuitive. I b=
elieve that many advanced use cases will take advantage from doing things t=
he TXHASH way (enabling stacking and cheaper fee sponsoring), but some deve=
lopers 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 f=
unctionality 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 propos=
als.
>
> - I am sympathetic to worries of changing legacy/v0 script. I failed to c=
onvince 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 VERI=
FY 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 fo=
r the rebindable signature use case
> All of the above changes I think can be decided on with minimal bikeshedd=
ing 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_C=
HECKSIG.
>> 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 securit=
y 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 Group=
s "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n email to bitcoindev+unsubscribe@googlegroups.com.
>> 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=
 "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/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io.

--=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/=
GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbt=
DU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com.

--b1=_LA1QV1HCVrFyMFi0XHZu8CQLMKFmbjV7s4C5aGxog
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Steven,</di=
v><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div=
><blockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border-col=
or: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px;">I'd like to fi=
rst express my disappointment with the
      amount of drama this letter has caused.<br></div></blockquote>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><=
div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Likewise. As=
 i mentioned earlier i think this bundle of capabilities is worth consideri=
ng for a use case driven soft fork. I felt like, despite the lack of substa=
ntive work on the proposal, we were finally going somewhere in the discussi=
on on extending Bitcoin's scripting capabilities.</div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fa=
mily: Arial, sans-serif; font-size: 14px;">Instead of addressing minor obje=
ctions to the design of the operations and working on demonstrating (real) =
use cases, the champion chose the route of political pressure on the Bitcoi=
n Core project. Signatories backed this approach.<br></div><div style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px;"><br></div><div>In changing =
Bitcoin, the process matters as much as the outcome. If Bitcoin can be chan=
ged through a shouting match and on the basis of misleading pseudo use case=
s, it would be a major fuck up. Likewise if a suboptimal change can be ramm=
ed through without addressing objections and reasonable requests from the t=
echnical community, by bamboozling industry stakeholders into the false dic=
hotomy "it's either this or ossification".</div><div><br></div><div>Bitcoin=
 Core cannot, in my opinion, facilitate setting such a precedent. Therefore=
 this effort sets us back a long way in getting a consensus change merged t=
here, and on the broader path of extending Bitcoin's scripting functionalit=
ies </div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; co=
lor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><blockq=
uote style=3D"border-left: 3px solid rgb(200, 200, 200); border-color: rgb(=
200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div style=
=3D"">It quite literally merely
      asks Core contributors to put this proposal on their agenda with
      some urgency.</div></blockquote><div style=3D""><br></div><div style=
=3D"">This is incorrect and misrepresenting the content of the letter. It s=
pecifically asks, i'm quoting "integration of CTV (PR <a href=3D"https://gi=
thub.com/bitcoin/bitcoin/pull/31989">#31989</a> or similar)". This is askin=
g 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 trust we <strike>all=
</strike> both agree it is inadvisable to change the Bitcoin Core decision =
process from making software changes based on objective rough technical con=
sensus toward making software changes based on the subjective intentions of=
 whoever has influence in the space at the moment.<br></div><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgr=
ound-color: rgb(255, 255, 255);"><br></div><blockquote style=3D"border-left=
: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); padding-l=
eft: 10px; color: rgb(102, 102, 102);"><div style=3D""><span>Given that onl=
y a handful of Core contributors had thus far participated in the conversat=
ion on the proposal elsewhere</span><br></div></blockquote><div style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgro=
und-color: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial,=
 sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(25=
5, 255, 255);">And pressure to merge code for an obviously controversial co=
nsensus change is a great way to make sure not more of them engage, if lurk=
ing at how <a href=3D"https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-co=
nsensus-on-a-first-step-towards-covenants/1509/37?u=3Dantoinep" title=3D"pr=
evious CTV discussions went">previous CTV discussions went</a> wasn't enoug=
h.</div><div style=3D""><br></div><blockquote style=3D"border-left: 3px sol=
id rgb(200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px=
; color: rgb(102, 102, 102);"><div style=3D"">it
      seemed like a suitable next step to communicate that we want Core
      contributors to provide their position within this conversation<br></=
div></blockquote><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div>=
<div style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0=
, 0, 0); background-color: rgb(255, 255, 255);">How could you ever think it=
 be a "suitable next step"? Bitcoin Core contributors spend their days main=
taining the existing Bitcoin network, where making it boringly stable  is s=
uccess. Asking the project to merge a contentious consensus change, disrega=
rding conceptual review, is just laughable. I don't see how piling a sign-o=
n letter on top of this would improve anything.</div><div style=3D"font-fam=
ily: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-co=
lor: rgb(255, 255, 255);"><br></div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255=
, 255);">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 bu=
ndle of capabilities). I am not sure how we bounce back from this, but it n=
ecessarily involves someone standing up and actually doing the work of addr=
essing 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.<br></div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb=
(255, 255, 255);"><br></div><div style=3D"font-family: Arial, sans-serif; f=
ont-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"=
>Best,<br>Antoine Poinsot<br></div><div class=3D"protonmail_quote">
        On Tuesday, June 17th, 2025 at 7:31 AM, Steven Roose &lt;steven@roo=
se.io&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
           =20
    <p>Hey all</p>
    <p><br>
    </p>
    <p>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.</p>
    <p>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.<br>
      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.<br>
      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.<br>
    </p>
    <p>On the proposal itself. I have heard some mentions of TXHASH and
      why we, as the developer community, wouldn't go  straight for
      TXHASH.</p>
    <ul>
      <li>I think TXHASH is too far from being ready at this point:<br>
      </li>
      <ul>
        <li>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.</li>
        <li>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
<a href=3D"https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-opti=
ons-for-sponsorring-and-stacking/1760" class=3D"moz-txt-link-freetext" targ=
et=3D"_blank" rel=3D"noreferrer nofollow noopener">https://delvingbitcoin.o=
rg/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/17=
60</a>)</li>
        <li>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.<br>
        </li>
      </ul>
      <li>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.<br>
      </li>
      <li>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.<br>
      </li>
      <li>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.</li>
      <li>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.<br>
      </li>
    </ul>
    <p>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. </p>
    <p>That being said, I'm in no way married to the exact details of
      the proposals.<br>
    </p>
    <ul>
      <li>I am sympathetic to worries of changing legacy/v0 script. I
        failed to convince myself of any valuable usage for bare CTV.</li>
      <li>I am sympathetic to the consideration of revisiting scriptSig
        and annex-related modifications to the template hash.<br>
      </li>
      <li>I am sympathetic to the decision to optimize better for the
        rebindable signature use cases, meaning:<br>
      </li>
      <ul>
        <li>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</li>
        <li>the addition of an INTERNALKEY opcode, saving an additional
          33 bytes for the rebindable signature use case</li>
      </ul>
    </ul>
    All of the above changes I think can be decided on with minimal
    bikeshedding and still encompass the same semantics of the original
    proposal.<br>
    <p><br>
    </p>
    <p>Best</p>
    <p>Steven<br>
    </p>
    <p><br>
    </p>
    <div class=3D"moz-cite-prefix">On 6/9/25 12:40, James O'Beirne wrote:<b=
r>
    </div>
    <blockquote type=3D"cite">
     =20
      Good morning,<br>
      <br>
      A letter has been published advocating for the final review and<br>
      activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and
      OP_CHECKSIGFROMSTACK<br>
      (BIP-348). <br>
      <br>
      The full text of the letter can be found at <a href=3D"https://ctv-cs=
fs.com" class=3D"moz-txt-link-freetext" target=3D"_blank" rel=3D"noreferrer=
 nofollow noopener">https://ctv-csfs.com</a>.
      It is<br>
      reproduced below.<br>
      <br>
      ---<br>
      <br>
      To the technical bitcoin community,<br>
      <br>
      We believe that the best next step for bitcoin would be to
      activate<br>
      OP_CHECKTEMPLATEVERIFY (CTV, BIP-119) and OP_CHECKSIGFROMSTACK
      (CSFS,<br>
      BIP-348). These opcodes enable functionality for a broad set of
      uses<br>
      that will allow bitcoin to preserve and expand its role as a
      scarce,<br>
      censorship-resistant store of value.<br>
      <br>
      While there are a few promising proposals to improve bitcoin at
      the<br>
      consensus layer which may someday be deployed, we believe that CTV
      and<br>
      CSFS are uniquely well reviewed, simple, and have been proven to
      be both<br>
      safe and widely demanded.<br>
      <br>
      CTV was first formalized in BIP-119 over 5 years ago. Despite many<br=
>
      attempts at refinement or replacement, it has remained the most
      widely<br>
      preferred method for enforcing pregenerated transaction sequences
      using<br>
      consensus. It unlocks valuable functionality for scaling
      solutions,<br>
      vaults, congestion control, non-custodial mining, discreet log<br>
      contracts, and more.<br>
      <br>
      CSFS is a primitive opcode that has been deployed to Blockstream=E2=
=80=99s<br>
      Elements for at least 8 years. It represents no significant<br>
      computational burden over bitcoin=E2=80=99s most often used opcode,
      OP_CHECKSIG.<br>
      It can be combined with CTV to implement ln-symmetry, a
      longstanding<br>
      improvement to Lightning. It also unlocks a variety of other use
      cases.<br>
      <br>
      We respectfully ask Bitcoin Core contributors to prioritize the
      review<br>
      and integration of CTV (PR #31989 or similar) and CSFS (PR #32247
      or<br>
      similar) within the next six months. We believe this timeline
      allows for<br>
      rigorous final review and activation planning.<br>
      <br>
      This request isn't meant to suggest that these contributors
      dictate the<br>
      consensus process, but rather it is an acknowledgement that before
      these<br>
      opcodes can be activated, they must be implemented in the most
      widely<br>
      used bitcoin client.<br>
      <br>
      As application and protocol developers, we are convinced of the<br>
      significant benefits that these changes would bring to end users
      of<br>
      bitcoin =E2=80=93 even if only considering their use for layer 1 secu=
rity
      and<br>
      layer 2 scaling solutions. We are optimistic that given the
      limited size<br>
      and scope of these changes in both concept and implementation,
      they<br>
      represent a realistic next step in the continuing and important
      work of<br>
      preserving bitcoin's unique promise.<br>
      <br>
      Signed, <br>
      <br>
      Abdel (Starkware)<br>
      Andrew Poelstra (@apoelstra)<br>
      Ben Carman (@benthecarman)<br>
      Ben Kaufman (@ben-kaufman)<br>
      Brandon Black (@reardencode)<br>
      Brian Langel (for Five Bells)<br>
      Buck Perley (@puckberley)<br>
      Calle (Cashu)<br>
      Calvin Kim (@kcalvinalvin)<br>
      Chun Wang (f2pool)<br>
      Christian Decker (@cdecker)<br>
      Coinjoined Chris (Bitsurance.eu)<br>
      Evan Kaloudis (for Zeus)<br>
      fiatjaf (@fiatjaf)<br>
      Floppy (@1440000bytes)<br>
      Gary Krause (@average-gary)<br>
      Harsha Goli (@arshbot)<br>
      Hunter Beast (@cryptoquick)<br>
      Jad Mubaslat (@champbronc2)<br>
      James O=E2=80=99Beirne (@jamesob)<br>
      Jameson Lopp (@jlopp)<br>
      Johan Halseth (@halseth)<br>
      Luke Childs (@lukechilds)<br>
      Matt Black (for Atomic Finance)<br>
      Michael Tidwell (@miketwenty1)<br>
      Nick Hansen (for Luxor Mining)<br>
      Nitesh (@nitesh_btc)<br>
      nvk (@nvk)<br>
      Owen Kemeys (for Foundation)<br>
      Paul Sztorc (@psztorc)<br>
      Portland.HODL (for MARA Pool)<br>
      Rijndael (@rot13maxi)<br>
      Rob Hamilton (@rob1ham)<br>
      Robin Linus (@RobinLinus)<br>
      Sanket Kanjalkar (@sanket1729)<br>
      Sean Ryan (Anchorage)<br>
      Seth for Privacy (for Cake Wallet)<br>
      Simanta Gautam (Alpen Labs)<br>
      Steven Roose (@stevenroose)<br>
      stutxo (@stutxo)<br>
      Talip (@otaliptus)<br>
      mononaut (@mononautical)<br>
      vnprc (@vnprc)<br>
      <br>
      -- <br>
      You received this message because you are subscribed to the Google
      Groups "Bitcoin Development Mailing List" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class=3D"moz-txt-link-freetext" href=3D"mailto:bi=
tcoindev+unsubscribe@googlegroups.com" rel=3D"noreferrer nofollow noopener"=
>bitcoindev+unsubscribe@googlegroups.com</a>.<br>
      To view this discussion visit <a href=3D"https://groups.google.com/d/=
msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegroups.com" =
target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.googl=
e.com/d/msgid/bitcoindev/a86c2737-db79-4f54-9c1d-51beeb765163n%40googlegrou=
ps.com</a>.<br>
    </blockquote>
 =20


<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io" target=3D"_blan=
k" rel=3D"noreferrer nofollow noopener">https://groups.google.com/d/msgid/b=
itcoindev/035f8b9c-9711-4edb-9d01-bef4a96320e1%40roose.io</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf=
7w6Zru3IKbtDU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
GLGZ3rEDfqaW8jAfIA6ac78uQzjEdYQaJf3ER9gd4e-wBXsiS2NK0wAj8LWK8VHf7w6Zru3IKbt=
DU5NM102jD8wMjjw8y7FmiDtQIy9U7Y4%3D%40protonmail.com</a>.<br />

--b1=_LA1QV1HCVrFyMFi0XHZu8CQLMKFmbjV7s4C5aGxog--