path: root/8c/87c6acbfa41eea9381296a59fa025569b4bb63

Delivery-date: Wed, 15 Jan 2025 12:09:17 -0800
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBYVLUC6AMGQELM6VKWY@googlegroups.com>)
	id 1tY9hT-0001aI-9e
	for bitcoindev@gnusha.org; Wed, 15 Jan 2025 12:09:17 -0800
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e572df6db3esf394267276.3
        for <bitcoindev@gnusha.org>; Wed, 15 Jan 2025 12:09:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1736971749; x=1737576549; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=;
        b=gUX5fEJWVVnMkEQHZkwoHLSuS79IGBWRlB4GlgyeFQTfleHL90+KNk4/4jZV/IYRdP
         JBY7FBkTO48Wh89UGfA+BmqNxE71Z0XgyEWXuJNL9g5LJQWOIR8fQOy0MKD/VTuscyNc
         msq2hUL3btofMjlbJH1UlRhxc/QIWXzsJdGH59mKJNLyvS5A8GwwUqvYyiGwUKBNrbA8
         lkxtWEWIhgFIVuUeFeaGjEbSTHHsb7Q2QRkdZH2kzK4YBBE/SXtP76KdumMqIr0jMTpD
         fbS0mBQ5JK4zw/K4Iipdt9Dszrt9NI8vh508e+MHRLEeaCwV8tkGGBe87gxAMyNGXzT3
         GyUw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736971749; x=1737576549; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=;
        b=QN/kvMBgmzWgqmXrMYoZ2EOXnYCmRwJaZX9Fm+D5II1gCM3m0cATIh5C9anamo7GWY
         +n7DS3hl59Yy58bCD/XLRMNKRmnTxwj4KWOUGppg9HXcejKk1Hc+2YSfw1ayS5GUvuW/
         1hmYO9H88mS6vgDKdMwkZFpeJVSjTfZrbbEadPmAhIx5UpTal2cDKFUH043CosUqhdLK
         Qg/nSCRu8M8nhDzKEtTyUcDkAdbUdNZdgPY6QrLsIWT8ajntBLfzEgoLUcdkBQR9W4sL
         8VFfzunLqPy4Ewj/jroqPlElIZ0bqpBaum0dAO+nqdhNKal9yBWwRlA0QdBHdEVfs6KN
         FDzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736971749; x=1737576549;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=;
        b=KRU9SGGHMEcBYFypXlB5Ia6pnyB87aOEzdDdEFZ9mnq1dDxQHTys2Wv6M7HPlN07Uw
         gh+aOzWWtNd7h+Xyf/o/V4RS91JcmR6bpRo/Y2+mpu43ua+aKAxwY6r0B5N/NMOjQNvL
         31M+FpbCPtEQ+0nIumRwqdu0ubmq8ylc2nGglhitCq/ylrsXE7R4t0tNXCV3VimDxXeO
         o5H4i2ksV83j8Y3CtlN2yDDfN0tmZgtwRs1Id25Pj5YpK+081w08XJDvCIaCSrsp30Ue
         WEU74TIK2d6TZBZpGHVh/JWi0I8OWQwe798OoerIWQphJLLCkVeP0HBaWyxFhomLZw9Z
         JfGA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXG4n2IH75kewNDHMwfXZrZRdxAWzSc+ipjY0Ad764e9xtFaWLQ4P9cG4Tfcf4N6jCX46pzUXba9J+w@gnusha.org
X-Gm-Message-State: AOJu0YwvK+QE2DhCEuEsZ4X2VseAVU5P+Hp/+4QqwWwyqY2CWNj7JO52
	jcr0uQoMvPGnXXthB2yEMvUeTspTYR7kdGhInnLI7ZxjSNc4pa6K
X-Google-Smtp-Source: AGHT+IHQDpq5KZKwOZMioQN0cw+hSrNLhcAUtKjfS5bcS5BkJ7mT+FfkEgm5xBKDgXBx0KvTqYF9WQ==
X-Received: by 2002:a25:8c1:0:b0:e3a:1735:b24e with SMTP id 3f1490d57ef6-e54edf25fb1mr19221866276.2.1736971748534;
        Wed, 15 Jan 2025 12:09:08 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:6ed6:0:b0:e57:32d7:dded with SMTP id 3f1490d57ef6-e579cb5e882ls217819276.1.-pod-prod-05-us;
 Wed, 15 Jan 2025 12:09:06 -0800 (PST)
X-Received: by 2002:a05:690c:9c03:b0:6ef:641a:2a90 with SMTP id 00721157ae682-6f5312be4bcmr245273107b3.32.1736971745871;
        Wed, 15 Jan 2025 12:09:05 -0800 (PST)
Received: by 2002:a05:690c:9a86:b0:6ef:7d10:5a2f with SMTP id 00721157ae682-6f5d2c70edcms7b3;
        Tue, 14 Jan 2025 06:14:39 -0800 (PST)
X-Received: by 2002:a05:690c:6ac9:b0:6ef:8c41:def8 with SMTP id 00721157ae682-6f53132900amr191465867b3.38.1736864078275;
        Tue, 14 Jan 2025 06:14:38 -0800 (PST)
Date: Tue, 14 Jan 2025 06:14:37 -0800 (PST)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <c7486012-79a3-46e4-a310-a3d0edb47e97n@googlegroups.com>
In-Reply-To: <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com>
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
 <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
 <CAEM=y+V9Gu0n7pLv1d+K1HfaFsB3kXg-LbtppyZG0xjAa7DBaA@mail.gmail.com>
 <CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA@mail.gmail.com>
 <BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd27VQfODaemn-jksB8bLFGoM8a70f3xjWI=@protonmail.com>
 <c411dee9-1937-42fd-bc66-d347ddbff506n@googlegroups.com>
 <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_534798_751735772.1736864077681"
X-Original-Sender: alicexbtong@gmail.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: -0.5 (/)

------=_Part_534798_751735772.1736864077681
Content-Type: multipart/alternative; 
	boundary="----=_Part_534799_1161673789.1736864077681"

------=_Part_534799_1161673789.1736864077681
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We have been discussing the objections shared by Jonas Nick in his=20
rationale:=20
https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4b5a51

Feel free to comment if you'd like to add something.

/dev/fd0
floppy disk guy

On Friday, January 3, 2025 at 5:45:29=E2=80=AFPM UTC+5:30 moonsettler wrote=
:

> Hi FLoppy,
>
> Of course I appreciate thoughtful evaluations.
>
> But my point stands, I encourage everyone to look at this table as means=
=20
> to engage in discussion not some indicator of "consensus" by any means.
>
> And I emphasized this, because there was a weird perception emerging, and=
=20
> even your own summary had this feel to it.
>
> BR,
> moonsettler
>
>
> Sent with Proton Mail secure email.
>
> On Thursday, January 2nd, 2025 at 4:16 PM, /dev /fd0 <alice...@gmail.com>=
=20
> wrote:
>
> > Hi moonsettler,
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does.=
=20
> They make it more efficient, and they also help other contracts.
> > Among them: Resumeable LN channels, Multi-party LN channels, Vaults, et=
c.
> >=20
> > I am aware of this and have used the comparison table in my=20
> [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY=
.
> >=20
> > > Calling it "unnecessary complexity" is not a valid technical=20
> observation in any shape or form. It would provide optimization for many=
=20
> contracts and use cases even if we had CAT. I explained this to you in=20
> private first, yet you keep insisting on this completely invalid objectio=
n.
> >=20
> > It is a valid objection and I find it disappointing that you think=20
> people will change their opinion about an opcode if you build [activation=
=20
> client][2] or a different table. If you read all the rationales, its not=
=20
> just me who finds this opcode irrelevant. Please respect the developers w=
ho=20
> shared their evaluations in the table even if you disagree with them. If=
=20
> you cannot appreciate efforts to review proposals and reach technical=20
> consensus, at least avoid calling reviews/evaluations as "voting".
> >=20
> > "Unnecessary" because LN symmetry (efficient) is possible without it.=
=20
> "Complexity" is introduced because it will be used for everything possibl=
e=20
> with it in bitcoin script and not just the use cases described in your=20
> email.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > [1]: https://gitlab.com/-/snippets/4777553
> > [2]: https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAA=
J
> > On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonsettler=
 wrote:
> >=20
> > > Hi Floppy,
> > >=20
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does.=
=20
> They make it more efficient, and they also help other contracts.
> > > Among them: Resumeable LN channels, Multi-party LN channels, Vaults,=
=20
> etc.
> > >=20
> > > Main benefit for the network: we can reduce the number of SigOps=20
> on-chain which benefits everyone that runs a validating node by making it=
=20
> more economic to use a single signature for multiple elements instead of=
=20
> using something like the ReKey technique.
> > >=20
> > > Calling it "unnecessary complexity" is not a valid technical=20
> observation in any shape or form. It would provide optimization for many=
=20
> contracts and use cases even if we had CAT. I explained this to you in=20
> private first, yet you keep insisting on this completely invalid objectio=
n.
> > >=20
> > > BR,
> > > moonsettler
> > >=20
> > > PS: I largely agree with everything Ethan said.
> > >=20
> > > Sent with Proton Mail secure email.
> > >=20
> > > On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 <
> alice...@gmail.com> wrote:
> > >=20
> > > > Hi Ethan,
> > > > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas=
=20
> OP_PAIRCOMMIT is a part of LNHANCE.
> > > >
> > > > In this context, OP_PAIRCOMMIT adds unnecessary complexity because=
=20
> LN SYMMETRY can be achieved with other opcodes.
> > > >
> > > > Note: The objections shared in this thread are a summarised version=
=20
> of all the rationales and not my person opinion.
> > > >
> > > > /dev/fd0
> > > > floppy disk guy
> > > >
> > > > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth...@gmail.com>=20
> wrote:
> > > >
> > > > > One of the CAT authors here
> > > > >
> > > > > > > [PAIR_COMMIT] Adds unnecessary complexity
> > > > > > That's a subjective value judgement it enables something that=
=20
> was no possible before which is interacting with Merkle trees and=20
> multi-element commitments in script. PAIRCOMMIT is not significantly more=
=20
> complicated than CAT, and in a lot of actual use cases CAT was desired fo=
r=20
> it's more complex and resource intensive to safely use CAT than PAIRCOMMI=
T=20
> due to witness malleability.
> > > > >
> > > > > PAIR_COMMIT (BIP-442) for all intents and purposes is as simple i=
n
> > > > > implementation at CAT (BIP-347). I have no technical objection to
> > > > > PAIRCOMMIT and it provides much needed functionality.
> > > > >
> > > > > My primary concern is not PAIRCOMMIT itself, but the rationale fo=
r=20
> PAIRCOMMIT.
> > > > >
> > > > > The rationale for PAIRCOMMIT rests on the assumption that the=20
> Bitcoin
> > > > > community does not want the expressiveness of CAT. If we assume=
=20
> this
> > > > > is the case, then we should be very careful PAIRCOMMIT does not=
=20
> enable
> > > > > this expressiveness as well. On the other hand, if the Bitcoin
> > > > > community does want the expressiveness of CAT, then we should mer=
ge
> > > > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT=
=20
> and it
> > > > > is likely that you can not simulate CAT with PAIRCOMMIT. That=20
> said, I
> > > > > am not convinced it is impossible that there is no way to simulat=
e=20
> CAT
> > > > > with PAIRCOMMIT, nor I do feel confident that I know how much les=
s
> > > > > powerful PAIRCOMMIT is than CAT.
> > > > >
> > > > > Playing devil's advocate for a second, if I was opposed to CAT on
> > > > > grounds that we should limit expressiveness I would want to reall=
y
> > > > > understand the limits of PAIRCOMMIT. For instance can you do=20
> arbitrary
> > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If=
=20
> not,
> > > > > why not?
> > > > >
> > > > > That said, I have not heard any argument against PAIRCOMMIT from=
=20
> those
> > > > > against CAT, so perhaps they are comfortable with it.
> > > > >
> > > > > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.
> > > > >
> > > > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitcoin=
=20
> Development
> > > > > Mailing List <bitco...@googlegroups.com> wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > One thing I would like to make clear before people get the wron=
g=20
> idea and think this is some form of voting, OP_INTERNALKEY and OP_PARCOMM=
IT=20
> is part of LNhance and will be part of the activation client we release=
=20
> soon. The only way to change that is to demonstrate actual harm. You liki=
ng=20
> something else more, is your problem. What you can do about it, is write=
=20
> your activation client and try to gain consensus on that. There are plent=
y=20
> of version bits available. Replacing PAIRCOMMIT with CAT would be really=
=20
> easy, but while CAT is indeed very popular and has a wide support base it=
=20
> is also strongly opposed by many who did not choose to participate. I'm n=
ot=20
> convinced that this table represents actual developer, let alone ecosyste=
m=20
> consensus. If you decide you want to run an alternative activation effort=
=20
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > > > >
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> > > > > > OP_PARCOMMIT
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> > > > > >
> > > > > > > OP_PARCOMMIT seems to be controversial at this moment.
> > > > > >
> > > > > > I strongly disagree. In my book that's not what controversial=
=20
> means. Literally nobody managed to come up with a single use case anyone=
=20
> worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No"=
=20
> from those that prefer CAT as plain trolling. This BIP is young, there is=
 a=20
> clear correlation between the age of the proposals and their support with=
=20
> the sole exception of APO.
> > > > > >
> > > > > > > Adds unnecessary complexity
> > > > > >
> > > > > > That's a subjective value judgement it enables something that=
=20
> was no possible before which is interacting with Merkle trees and=20
> multi-element commitments in script. PAIRCOMMIT is not significantly more=
=20
> complicated than CAT, and in a lot of actual use cases CAT was desired fo=
r=20
> it's more complex and resource intensive to safely use CAT than PAIRCOMMI=
T=20
> due to witness malleability.
> > > > > >
> > > > > > > Not convinced it is impossible that there is no way to=20
> simulate CAT with PAIRCOMMIT, nor confident how much less powerful=20
> PAIRCOMMIT is than CAT.
> > > > > >
> > > > > > This is sufficiently addressed in the BIP.
> > > > > >
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> > > > > > OP_VAULT
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> > > > > >
> > > > > > > No demand for vaults.
> > > > > >
> > > > > > It's safe to completely ignore that "argument".
> > > > > >
> > > > > > BR,
> > > > > > moonsettler
> > > > > >
> > > > > >
> > > > > > On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 <
> alice...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi Bitcoin Developers,
> > > > > > >
> > > > > > > I had shared covenants support wiki page link here on [mailin=
g=20
> list][1] in the last week of November 2024. Multiple changes were made=20
> based on the feedback:
> > > > > > >
> > > > > > > - Removed 'community support' from 'No'. Rephrased definition=
s=20
> for 'Prefer' and 'Evaluating'.
> > > > > > > - Added LNHANCE category for a combination of opcodes.
> > > > > > > - Added links for BIP drafts and a column for 'rationale'.
> > > > > > > - Created a separate table for evaluations without a rational=
e.
> > > > > > >
> > > > > > > Murch and Gloria shared their feedback in the bitcoin optech=
=20
> [podcast 333][2]. I have started working on a [page][3] that lists use=20
> cases, prototype links and primitives used. We can still add more use cas=
es=20
> in it. This list does not include use cases enabled by=20
> [OP_CHECKSIGFROMSTACK][4] alone or in combination with other opcodes like=
=20
> [LN SYMMETRY][5].
> > > > > > >
> > > > > > > I had verified each entry to avoid spam and fake evaluations.=
=20
> Rearden was assigned moderator permissions on 8 December 2024 by Theymos =
to=20
> help me with the moderations. Some edits have been approved by other=20
> moderators.
> > > > > > >
> > > > > > > Some insights from the table that could help developers=20
> working on different covenant proposals:
> > > > > > >
> > > > > > > 1. Multiple ways to achieve LN symmetry were discovered.=20
> SIGHASH_APO lacks interest among developers, contrary to the belief prior=
=20
> to this exercise.
> > > > > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part o=
f=20
> multiple covenant proposals.
> > > > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY=
=20
> are not reviewed by enough developers. OP_PARCOMMIT seems to be=20
> controversial at this moment.
> > > > > > >
> > > > > > > Objections:
> > > > > > >
> > > > > > > ```
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > SIGHASH_APO
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > LN SYMMETRY is possible with combination of a few opcodes=20
> which is more efficient. Its not the best option for covenants and cannot=
=20
> be used to improve Ark. Some developers prefer opcodes and not sighash=20
> flags.
> > > > > > >
> > > > > > > Seems to be the result of an attempt to fix signatures to mak=
e=20
> them work for a specific use-case, but the end-result is hard-to-reason=
=20
> (for me) and not flexible. In general, SIGHASH flags are an encoding of=
=20
> specific predicates on the transaction, and I think the Script is better=
=20
> suited to carry the predicate. There is no interesting SIGHASH flag that=
=20
> couldn't be functionally simulated by introspection + CHECKSIGFROMSTACK (=
or=20
> other Script-based approaches), and that seems to me a much cleaner and=
=20
> ergonomic way to achieve the same goals.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_TXHASH
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > More expressive, many flag configurations, untested and=20
> undesirable use cases. Unaddressed comments in the BIP and the delay=20
> doesn't make sense because OP_CHECKTEMPLATEVERIFY can be upgraded later t=
o=20
> achieve the same thing. Makes hash caching complex, potentially opening u=
p=20
> DoS vectors or quadratic sighash.
> > > > > > >
> > > > > > > Most templates you'd obtain with various combinations of=20
> parameters are meaningless. It implements state-carrying UTXOs in a very=
=20
> dirty way: adding additional inputs/outputs with no other meaning than=20
> "storing some state". This is ugly, inefficient, and bloats the UTXO set =
-=20
> and it definitely will happen if TXHASH is enabled without also enabling =
a=20
> clean way to carry state.
> > > > > > >
> > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine=
=20
> tune it to what people are actually using covenants for, instead of=20
> prematurely optimizing everything with no data.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_VAULT
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > No demand for vaults. Customized for a specific use case.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_CAT
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > Can be used for various complex scripts including undesirable=
=20
> use cases (DEX, AMM and Hashrate Escrow). Enables granular transaction=20
> introspection through abuse of schnorr signatures and OP_CHECKSIG. Can be=
=20
> used for interesting use cases but alone does it poorly and inefficiently=
.
> > > > > > >
> > > > > > > People can and will litter the chain with inefficient/ugly=20
> Scripts if activated alone. Since it happens to enable generic=20
> introspection by accident, and therefore an ugly version of state-carryin=
g=20
> UTXOs, it shouldn't be enabled without more ergonomic opcodes for those u=
se=20
> cases.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_INTERNALKEY
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > There are 3 'No' in the table, I couldn't find anything=20
> relevant in the rationales.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_PAIRCOMMIT
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > Adds unnecessary complexity, redundant if OP_CAT is activated=
=20
> in future and added for specific use case. LN SYMMETRY is possible withou=
t=20
> this opcode. It does not compose with anything that involves transaction=
=20
> introspection due to its specified tagged hash. Some developers prefer=20
> OP_CAT.
> > > > > > >
> > > > > > > Not convinced it is impossible that there is no way to=20
> simulate CAT with PAIRCOMMIT, nor confident how much less powerful=20
> PAIRCOMMIT is than CAT.
> > > > > > >
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > > OP_CHECKTEMPLATEVERIFY
> > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > > > > > >
> > > > > > > Limited in scope and not recursive.
> > > > > > > ```
> > > > > > >
> > > > > > > I have tried my best to remain unbiased in writing this=20
> summary and approving edits. There are a few things that I want to share=
=20
> and it could be a result of the aggressive marketing:
> > > > > > >
> > > > > > > - A spammer had edited the table to remove all evaluations=20
> except in favor of OP_CAT and it was rejected.
> > > > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention=20
> anything about other opcodes and SIGHASH_APO. It is only focused on OP_CA=
T=20
> however evaluations exist in the table.
> > > > > > > - I [requested][7] Udev (CatSwap) to add details about=20
> evaluation of other opcodes and SIGHASH_APO.
> > > > > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with=
=20
> incorrect signet stats and seems to be rephrased version of another=20
> rationale. Evaluation had 'weak' for OP_CTV before adding the rationale.
> > > > > > > - An edit with duplicate rationale (in support of OP_CAT) was=
=20
> rejected because sharing the link for a rationale submitted by other=20
> developer adds no value in the table.
> > > > > > >
> > > > > > > Evaluations without a rationale have some 'No' in different=
=20
> cells. Although none of them are backed by a rationale so cannot be=20
> considered for consensus discussion. The table is still updated regularly=
=20
> so you may see some of them with a rationale in 2025. Any suggestions to=
=20
> help achieve technical consensus are most welcome.
> > > > > > >
> > > > > > > What's next?
> > > > > > >
> > > > > > > - More rationales in the table
> > > > > > > - Discuss objections on mailing list (if any)
> > > > > > > - Workshops
> > > > > > > - Add a table for economic nodes and their opinion
> > > > > > > - Build activation client and discuss parameters
> > > > > > >
> > > > > > > Finally, I would thank all the developers who added their=20
> evaluations in the table and everyone who shared updates on twitter. It w=
as=20
> a coordinated effort to reach some technical consensus. You can read all=
=20
> the rationales in detail to understand different perspectives and reasons=
=20
> to support a combination of opcodes over others.
> > > > > > >
> > > > > > > [1]:=20
> https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ
> > > > > > > [2]: https://bitcoinops.org/en/podcast/2024/12/17/
> > > > > > > [3]: https://en.bitcoin.it/wiki/Covenants_Uses
> > > > > > > [4]: https://github.com/bitcoin/bips/blob/master/bip-0348.md
> > > > > > > [5]:=20
> https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
> > > > > > > [6]:=20
> https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> > > > > > > [7]:=20
> https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permali=
nk_comment_id=3D5359072#gistcomment-5359072
> > > > > > > [8]:=20
> https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=3Dprev&o=
ldid=3D70520
> > > > > > >
> > > > > > > /dev/fd0
> > > > > > > floppy disk guy
> > > > > > >
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the=
=20
> Google Groups "Bitcoin Development Mailing List" group.
> > > > > > > To unsubscribe from this group and stop receiving emails from=
=20
> it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a4=
2a9a9007n%40googlegroups.com
> .
> > > > > >
> > > > > > --
> > > > > > You received this message because you are subscribed to the=20
> Google Groups "Bitcoin Development Mailing List" group.
> > > > > > To unsubscribe from this group and stop receiving emails from=
=20
> it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmc=
uQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frB=
WXac%3D%40protonmail.com
> .
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Googl=
e=20
> Groups "Bitcoin Development Mailing List" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,=
=20
> send an email to bitcoindev+...@googlegroups.com.
> > > > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1=
HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.com
> .
> >=20
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347=
ddbff506n%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/=
c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com.

------=_Part_534799_1161673789.1736864077681
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We have been discussing the objections shared by Jonas Nick in his rational=
e: <a href=3D"https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4=
b5a51">https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4b5a51</=
a><br /><br />Feel free to comment if you'd like to add something.<br /><di=
v><br /></div><div>/dev/fd0</div><div>floppy disk guy<br /><br /></div><div=
 class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, Ja=
nuary 3, 2025 at 5:45:29=E2=80=AFPM UTC+5:30 moonsettler wrote:<br/></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left:=
 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi FLoppy,
<br>
<br>Of course I appreciate thoughtful evaluations.
<br>
<br>But my point stands, I encourage everyone to look at this table as mean=
s to engage in discussion not some indicator of &quot;consensus&quot; by an=
y means.
<br>
<br>And I emphasized this, because there was a weird perception emerging, a=
nd even your own summary had this feel to it.
<br>
<br>BR,
<br>moonsettler
<br>
<br>
<br>Sent with Proton Mail secure email.
<br>
<br>On Thursday, January 2nd, 2025 at 4:16 PM, /dev /fd0 &lt;<a href data-e=
mail-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Hi moonsettler,
<br>&gt; &gt; Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhan=
ce does. They make it more efficient, and they also help other contracts.
<br>&gt; Among them: Resumeable LN channels, Multi-party LN channels, Vault=
s, etc.
<br>&gt;=20
<br>&gt; I am aware of this and have used the comparison table in my [ratio=
nale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
<br>&gt;=20
<br>&gt; &gt; Calling it &quot;unnecessary complexity&quot; is not a valid =
technical observation in any shape or form. It would provide optimization f=
or many contracts and use cases even if we had CAT. I explained this to you=
 in private first, yet you keep insisting on this completely invalid object=
ion.
<br>&gt;=20
<br>&gt; It is a valid objection and I find it disappointing that you think=
 people will change their opinion about an opcode if you build [activation =
client][2] or a different table. If you read all the rationales, its not ju=
st me who finds this opcode irrelevant. Please respect the developers who s=
hared their evaluations in the table even if you disagree with them. If you=
 cannot appreciate efforts to review proposals and reach technical consensu=
s, at least avoid calling reviews/evaluations as &quot;voting&quot;.
<br>&gt;=20
<br>&gt; &quot;Unnecessary&quot; because LN symmetry (efficient) is possibl=
e without it. &quot;Complexity&quot; is introduced because it will be used =
for everything possible with it in bitcoin script and not just the use case=
s described in your email.
<br>&gt;=20
<br>&gt; /dev/fd0
<br>&gt; floppy disk guy
<br>&gt;=20
<br>&gt; [1]: <a href=3D"https://gitlab.com/-/snippets/4777553" target=3D"_=
blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Den&amp;q=3Dhttps://gitlab.com/-/snippets/4777553&amp;source=3Dgmail&am=
p;ust=3D1736950171965000&amp;usg=3DAOvVaw0HSElHlm4jTJOjUcAcUNBy">https://gi=
tlab.com/-/snippets/4777553</a>
<br>&gt; [2]: <a href=3D"https://groups.google.com/g/bitcoindev/c/QOnpM4Ixm=
ms/m/eodYc71lDAAJ" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/g/=
bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ&amp;source=3Dgmail&amp;ust=3D173695=
0171965000&amp;usg=3DAOvVaw176WiEe9X8xwddafZbZuAx">https://groups.google.co=
m/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ</a>
<br>&gt; On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonse=
ttler wrote:
<br>&gt;=20
<br>&gt; &gt; Hi Floppy,
<br>&gt; &gt;=20
<br>&gt; &gt; Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhan=
ce does. They make it more efficient, and they also help other contracts.
<br>&gt; &gt; Among them: Resumeable LN channels, Multi-party LN channels, =
Vaults, etc.
<br>&gt; &gt;=20
<br>&gt; &gt; Main benefit for the network: we can reduce the number of Sig=
Ops on-chain which benefits everyone that runs a validating node by making =
it more economic to use a single signature for multiple elements instead of=
 using something like the ReKey technique.
<br>&gt; &gt;=20
<br>&gt; &gt; Calling it &quot;unnecessary complexity&quot; is not a valid =
technical observation in any shape or form. It would provide optimization f=
or many contracts and use cases even if we had CAT. I explained this to you=
 in private first, yet you keep insisting on this completely invalid object=
ion.
<br>&gt; &gt;=20
<br>&gt; &gt; BR,
<br>&gt; &gt; moonsettler
<br>&gt; &gt;=20
<br>&gt; &gt; PS: I largely agree with everything Ethan said.
<br>&gt; &gt;=20
<br>&gt; &gt; Sent with Proton Mail secure email.
<br>&gt; &gt;=20
<br>&gt; &gt; On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 &lt;<a h=
ref data-email-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; Hi Ethan,
<br>&gt; &gt; &gt; OP_CAT is not proposed as an opcode to enable LN SYMMETR=
Y. Whereas OP_PAIRCOMMIT is a part of LNHANCE.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; In this context, OP_PAIRCOMMIT adds unnecessary complexi=
ty because LN SYMMETRY can be achieved with other opcodes.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; Note: The objections shared in this thread are a summari=
sed version of all the rationales and not my person opinion.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; /dev/fd0
<br>&gt; &gt; &gt; floppy disk guy
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman &lt;<a href =
data-email-masked rel=3D"nofollow">eth...@gmail.com</a>&gt; wrote:
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; One of the CAT authors here
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; [PAIR_COMMIT] Adds unnecessary complexity
<br>&gt; &gt; &gt; &gt; &gt; That&#39;s a subjective value judgement it ena=
bles something that was no possible before which is interacting with Merkle=
 trees and multi-element commitments in script. PAIRCOMMIT is not significa=
ntly more complicated than CAT, and in a lot of actual use cases CAT was de=
sired for it&#39;s more complex and resource intensive to safely use CAT th=
an PAIRCOMMIT due to witness malleability.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; PAIR_COMMIT (BIP-442) for all intents and purposes =
is as simple in
<br>&gt; &gt; &gt; &gt; implementation at CAT (BIP-347). I have no technica=
l objection to
<br>&gt; &gt; &gt; &gt; PAIRCOMMIT and it provides much needed functionalit=
y.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; My primary concern is not PAIRCOMMIT itself, but th=
e rationale for PAIRCOMMIT.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; The rationale for PAIRCOMMIT rests on the assumptio=
n that the Bitcoin
<br>&gt; &gt; &gt; &gt; community does not want the expressiveness of CAT. =
If we assume this
<br>&gt; &gt; &gt; &gt; is the case, then we should be very careful PAIRCOM=
MIT does not enable
<br>&gt; &gt; &gt; &gt; this expressiveness as well. On the other hand, if =
the Bitcoin
<br>&gt; &gt; &gt; &gt; community does want the expressiveness of CAT, then=
 we should merge
<br>&gt; &gt; &gt; &gt; CAT. PAIRCOMMIT is well designed to be less express=
ive than CAT and it
<br>&gt; &gt; &gt; &gt; is likely that you can not simulate CAT with PAIRCO=
MMIT. That said, I
<br>&gt; &gt; &gt; &gt; am not convinced it is impossible that there is no =
way to simulate CAT
<br>&gt; &gt; &gt; &gt; with PAIRCOMMIT, nor I do feel confident that I kno=
w how much less
<br>&gt; &gt; &gt; &gt; powerful PAIRCOMMIT is than CAT.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Playing devil&#39;s advocate for a second, if I was=
 opposed to CAT on
<br>&gt; &gt; &gt; &gt; grounds that we should limit expressiveness I would=
 want to really
<br>&gt; &gt; &gt; &gt; understand the limits of PAIRCOMMIT. For instance c=
an you do arbitrary
<br>&gt; &gt; &gt; &gt; computation by building STARKs with PAIRCOMMIT merk=
le trees? If not,
<br>&gt; &gt; &gt; &gt; why not?
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; That said, I have not heard any argument against PA=
IRCOMMIT from those
<br>&gt; &gt; &gt; &gt; against CAT, so perhaps they are comfortable with i=
t.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Since I am in favor of CAT, I am also in favor of P=
AIRCOMMIT.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM &#39;moonse=
ttler&#39; via Bitcoin Development
<br>&gt; &gt; &gt; &gt; Mailing List &lt;<a href data-email-masked rel=3D"n=
ofollow">bitco...@googlegroups.com</a>&gt; wrote:
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Hi All,
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; One thing I would like to make clear before pe=
ople get the wrong idea and think this is some form of voting, OP_INTERNALK=
EY and OP_PARCOMMIT is part of LNhance and will be part of the activation c=
lient we release soon. The only way to change that is to demonstrate actual=
 harm. You liking something else more, is your problem. What you can do abo=
ut it, is write your activation client and try to gain consensus on that. T=
here are plenty of version bits available. Replacing PAIRCOMMIT with CAT wo=
uld be really easy, but while CAT is indeed very popular and has a wide sup=
port base it is also strongly opposed by many who did not choose to partici=
pate. I&#39;m not convinced that this table represents actual developer, le=
t alone ecosystem consensus. If you decide you want to run an alternative a=
ctivation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; OP_PARCOMMIT
<br>&gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_PARCOMMIT seems to be controversial at=
 this moment.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; I strongly disagree. In my book that&#39;s not=
 what controversial means. Literally nobody managed to come up with a singl=
e use case anyone worth noting objects to for PAIRCOMMIT. Also inclined to =
ignore the &quot;No&quot; from those that prefer CAT as plain trolling. Thi=
s BIP is young, there is a clear correlation between the age of the proposa=
ls and their support with the sole exception of APO.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Adds unnecessary complexity
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; That&#39;s a subjective value judgement it ena=
bles something that was no possible before which is interacting with Merkle=
 trees and multi-element commitments in script. PAIRCOMMIT is not significa=
ntly more complicated than CAT, and in a lot of actual use cases CAT was de=
sired for it&#39;s more complex and resource intensive to safely use CAT th=
an PAIRCOMMIT due to witness malleability.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Not convinced it is impossible that there=
 is no way to simulate CAT with PAIRCOMMIT, nor confident how much less pow=
erful PAIRCOMMIT is than CAT.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; This is sufficiently addressed in the BIP.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; OP_VAULT
<br>&gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; No demand for vaults.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; It&#39;s safe to completely ignore that &quot;=
argument&quot;.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; BR,
<br>&gt; &gt; &gt; &gt; &gt; moonsettler
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; On Tuesday, December 31st, 2024 at 9:23 AM, /d=
ev /fd0 &lt;<a href data-email-masked rel=3D"nofollow">alice...@gmail.com</=
a>&gt; wrote:
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Hi Bitcoin Developers,
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; I had shared covenants support wiki page =
link here on [mailing list][1] in the last week of November 2024. Multiple =
changes were made based on the feedback:
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Removed &#39;community support&#39; fro=
m &#39;No&#39;. Rephrased definitions for &#39;Prefer&#39; and &#39;Evaluat=
ing&#39;.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Added LNHANCE category for a combinatio=
n of opcodes.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Added links for BIP drafts and a column=
 for &#39;rationale&#39;.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Created a separate table for evaluation=
s without a rationale.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Murch and Gloria shared their feedback in=
 the bitcoin optech [podcast 333][2]. I have started working on a [page][3]=
 that lists use cases, prototype links and primitives used. We can still ad=
d more use cases in it. This list does not include use cases enabled by [OP=
_CHECKSIGFROMSTACK][4] alone or in combination with other opcodes like [LN =
SYMMETRY][5].
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; I had verified each entry to avoid spam a=
nd fake evaluations. Rearden was assigned moderator permissions on 8 Decemb=
er 2024 by Theymos to help me with the moderations. Some edits have been ap=
proved by other moderators.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Some insights from the table that could h=
elp developers working on different covenant proposals:
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; 1. Multiple ways to achieve LN symmetry w=
ere discovered. SIGHASH_APO lacks interest among developers, contrary to th=
e belief prior to this exercise.
<br>&gt; &gt; &gt; &gt; &gt; &gt; 2. OP_CHECKSIGFROMSTACK has unanimous sup=
port and is a part of multiple covenant proposals.
<br>&gt; &gt; &gt; &gt; &gt; &gt; 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_C=
HECKCONTRACTVERIFY are not reviewed by enough developers. OP_PARCOMMIT seem=
s to be controversial at this moment.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Objections:
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; ```
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; SIGHASH_APO
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; LN SYMMETRY is possible with combination =
of a few opcodes which is more efficient. Its not the best option for coven=
ants and cannot be used to improve Ark. Some developers prefer opcodes and =
not sighash flags.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Seems to be the result of an attempt to f=
ix signatures to make them work for a specific use-case, but the end-result=
 is hard-to-reason (for me) and not flexible. In general, SIGHASH flags are=
 an encoding of specific predicates on the transaction, and I think the Scr=
ipt is better suited to carry the predicate. There is no interesting SIGHAS=
H flag that couldn&#39;t be functionally simulated by introspection + CHECK=
SIGFROMSTACK (or other Script-based approaches), and that seems to me a muc=
h cleaner and ergonomic way to achieve the same goals.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_TXHASH
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; More expressive, many flag configurations=
, untested and undesirable use cases. Unaddressed comments in the BIP and t=
he delay doesn&#39;t make sense because OP_CHECKTEMPLATEVERIFY can be upgra=
ded later to achieve the same thing. Makes hash caching complex, potentiall=
y opening up DoS vectors or quadratic sighash.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Most templates you&#39;d obtain with vari=
ous combinations of parameters are meaningless. It implements state-carryin=
g UTXOs in a very dirty way: adding additional inputs/outputs with no other=
 meaning than &quot;storing some state&quot;. This is ugly, inefficient, an=
d bloats the UTXO set - and it definitely will happen if TXHASH is enabled =
without also enabling a clean way to carry state.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Follow up with an upgrade to OP_CHECKTEMP=
LATEVERIFY can fine tune it to what people are actually using covenants for=
, instead of prematurely optimizing everything with no data.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_VAULT
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; No demand for vaults. Customized for a sp=
ecific use case.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_CAT
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Can be used for various complex scripts i=
ncluding undesirable use cases (DEX, AMM and Hashrate Escrow). Enables gran=
ular transaction introspection through abuse of schnorr signatures and OP_C=
HECKSIG. Can be used for interesting use cases but alone does it poorly and=
 inefficiently.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; People can and will litter the chain with=
 inefficient/ugly Scripts if activated alone. Since it happens to enable ge=
neric introspection by accident, and therefore an ugly version of state-car=
rying UTXOs, it shouldn&#39;t be enabled without more ergonomic opcodes for=
 those use cases.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_INTERNALKEY
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; There are 3 &#39;No&#39; in the table, I =
couldn&#39;t find anything relevant in the rationales.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_PAIRCOMMIT
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Adds unnecessary complexity, redundant if=
 OP_CAT is activated in future and added for specific use case. LN SYMMETRY=
 is possible without this opcode. It does not compose with anything that in=
volves transaction introspection due to its specified tagged hash. Some dev=
elopers prefer OP_CAT.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Not convinced it is impossible that there=
 is no way to simulate CAT with PAIRCOMMIT, nor confident how much less pow=
erful PAIRCOMMIT is than CAT.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt; OP_CHECKTEMPLATEVERIFY
<br>&gt; &gt; &gt; &gt; &gt; &gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Limited in scope and not recursive.
<br>&gt; &gt; &gt; &gt; &gt; &gt; ```
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; I have tried my best to remain unbiased i=
n writing this summary and approving edits. There are a few things that I w=
ant to share and it could be a result of the aggressive marketing:
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; - A spammer had edited the table to remov=
e all evaluations except in favor of OP_CAT and it was rejected.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - [Rationale][6] added by Aaron (sCrypt) =
does not mention anything about other opcodes and SIGHASH_APO. It is only f=
ocused on OP_CAT however evaluations exist in the table.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - I [requested][7] Udev (CatSwap) to add =
details about evaluation of other opcodes and SIGHASH_APO.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Last [edit][8] by Roujiamo (bitdollar) =
has a rationale with incorrect signet stats and seems to be rephrased versi=
on of another rationale. Evaluation had &#39;weak&#39; for OP_CTV before ad=
ding the rationale.
<br>&gt; &gt; &gt; &gt; &gt; &gt; - An edit with duplicate rationale (in su=
pport of OP_CAT) was rejected because sharing the link for a rationale subm=
itted by other developer adds no value in the table.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Evaluations without a rationale have some=
 &#39;No&#39; in different cells. Although none of them are backed by a rat=
ionale so cannot be considered for consensus discussion. The table is still=
 updated regularly so you may see some of them with a rationale in 2025. An=
y suggestions to help achieve technical consensus are most welcome.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; What&#39;s next?
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; - More rationales in the table
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Discuss objections on mailing list (if =
any)
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Workshops
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Add a table for economic nodes and thei=
r opinion
<br>&gt; &gt; &gt; &gt; &gt; &gt; - Build activation client and discuss par=
ameters
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; Finally, I would thank all the developers=
 who added their evaluations in the table and everyone who shared updates o=
n twitter. It was a coordinated effort to reach some technical consensus. Y=
ou can read all the rationales in detail to understand different perspectiv=
es and reasons to support a combination of opcodes over others.
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; [1]: <a href=3D"https://groups.google.com=
/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ" target=3D"_blank" rel=3D"nofoll=
ow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp=
s://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ&amp;source=
=3Dgmail&amp;ust=3D1736950171965000&amp;usg=3DAOvVaw3bOR11RN0ICQwdtzFtM2oO"=
>https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [2]: <a href=3D"https://bitcoinops.org/en=
/podcast/2024/12/17/" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://bitcoinops.org/en/=
podcast/2024/12/17/&amp;source=3Dgmail&amp;ust=3D1736950171965000&amp;usg=
=3DAOvVaw1YNRFxey7uB-En-XmoU2Wv">https://bitcoinops.org/en/podcast/2024/12/=
17/</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [3]: <a href=3D"https://en.bitcoin.it/wik=
i/Covenants_Uses" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://en.bitcoin.it/wiki/C=
ovenants_Uses&amp;source=3Dgmail&amp;ust=3D1736950171965000&amp;usg=3DAOvVa=
w1Zz9_cF_YEmn8e3fPJRRWL">https://en.bitcoin.it/wiki/Covenants_Uses</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [4]: <a href=3D"https://github.com/bitcoi=
n/bips/blob/master/bip-0348.md" target=3D"_blank" rel=3D"nofollow" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.c=
om/bitcoin/bips/blob/master/bip-0348.md&amp;source=3Dgmail&amp;ust=3D173695=
0171965000&amp;usg=3DAOvVaw23Tdty6toDC934hdZvyUIP">https://github.com/bitco=
in/bips/blob/master/bip-0348.md</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [5]: <a href=3D"https://gist.github.com/A=
deman/4a14614fa850511d63a5b2a9b5104cb7" target=3D"_blank" rel=3D"nofollow" =
data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://=
gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7&amp;source=3Dgmail&=
amp;ust=3D1736950171965000&amp;usg=3DAOvVaw1xIA-WtF3DlkCJ1BvIDp-J">https://=
gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [6]: <a href=3D"https://gist.github.com/g=
itzhou/dc92c41db1987db16fe665c26bc56dd9" target=3D"_blank" rel=3D"nofollow"=
 data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps:/=
/gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9&amp;source=3Dgmai=
l&amp;ust=3D1736950171965000&amp;usg=3DAOvVaw065hUCINbNQwfEpt8mnCK5">https:=
//gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [7]: <a href=3D"https://gist.github.com/u=
devswap/b768d20d62549922b9e72428ef9eb608?permalink_comment_id=3D5359072#gis=
tcomment-5359072" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.github.com/udev=
swap/b768d20d62549922b9e72428ef9eb608?permalink_comment_id%3D5359072%23gist=
comment-5359072&amp;source=3Dgmail&amp;ust=3D1736950171965000&amp;usg=3DAOv=
Vaw3-8Y6DrPS4XJjSk_ipDeX-">https://gist.github.com/udevswap/b768d20d6254992=
2b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5359072</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt; [8]: <a href=3D"https://en.bitcoin.it/w/i=
ndex.php?title=3DCovenants_support&amp;diff=3Dprev&amp;oldid=3D70520" targe=
t=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://en.bitcoin.it/w/index.php?title%3DCovenants_s=
upport%26diff%3Dprev%26oldid%3D70520&amp;source=3Dgmail&amp;ust=3D173695017=
1965000&amp;usg=3DAOvVaw1ZmVTfPkg4HpgippH-tAJK">https://en.bitcoin.it/w/ind=
ex.php?title=3DCovenants_support&amp;diff=3Dprev&amp;oldid=3D70520</a>
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; /dev/fd0
<br>&gt; &gt; &gt; &gt; &gt; &gt; floppy disk guy
<br>&gt; &gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; &gt; &gt; You received this message because you are=
 subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quo=
t; group.
<br>&gt; &gt; &gt; &gt; &gt; &gt; To unsubscribe from this group and stop r=
eceiving emails from it, send an email to <a href data-email-masked rel=3D"=
nofollow">bitcoindev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; &gt; &gt; To view this discussion visit <a href=3D"=
https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a=
9a9007n%40googlegroups.com" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.googl=
e.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%2540googlegr=
oups.com&amp;source=3Dgmail&amp;ust=3D1736950171965000&amp;usg=3DAOvVaw0u43=
bZGkIAelMJr_lndNzy">https://groups.google.com/d/msgid/bitcoindev/38a6f252-a=
fe9-4155-a341-11a42a9a9007n%40googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; &gt; You received this message because you are subs=
cribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; gr=
oup.
<br>&gt; &gt; &gt; &gt; &gt; To unsubscribe from this group and stop receiv=
ing emails from it, send an email to <a href data-email-masked rel=3D"nofol=
low">bitcoindev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; &gt; To view this discussion visit <a href=3D"https=
://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9=
r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D=
%40protonmail.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/=
msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK=
_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%253D%2540protonmail.com&a=
mp;source=3Dgmail&amp;ust=3D1736950171965000&amp;usg=3DAOvVaw0bkAPmfT2ctdXS=
US_fi1wR">https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweI=
hzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtM=
WXXV2frBWXac%3D%40protonmail.com</a>.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; You received this message because you are subscribe=
d to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; &gt; &gt; &gt; To unsubscribe from this group and stop receiving e=
mails from it, send an email to <a href data-email-masked rel=3D"nofollow">=
bitcoindev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; To view this discussion visit <a href=3D"https://gr=
oups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-L=
btppyZG0xjAa7DBaA%40mail.gmail.com" target=3D"_blank" rel=3D"nofollow" data=
-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://grou=
ps.google.com/d/msgid/bitcoindev/CAEM%253Dy%252BV9Gu0n7pLv1d%252BK1HfaFsB3k=
Xg-LbtppyZG0xjAa7DBaA%2540mail.gmail.com&amp;source=3Dgmail&amp;ust=3D17369=
50171965000&amp;usg=3DAOvVaw0V0HEyh-qxnAoEeXtu6rJU">https://groups.google.c=
om/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7=
DBaA%40mail.gmail.com</a>.
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
c411dee9-1937-42fd-bc66-d347ddbff506n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1736950171965000&amp;usg=3DAOvVaw1i_DUcKsKyJxdpVlr8Buwu">https=
://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff50=
6n%40googlegroups.com</a>.
<br></blockquote></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/c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com</a>.<br />

------=_Part_534799_1161673789.1736864077681--

------=_Part_534798_751735772.1736864077681--