path: root/b3/c337420fd3f94cbc1d3699bd0a41b000f210d8

Delivery-date: Thu, 02 Jan 2025 07:42:36 -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+bncBCU2P6FJ3EBBBYPH3K5QMGQEFDA2CKQ@googlegroups.com>)
	id 1tTNLG-00016F-Km
	for bitcoindev@gnusha.org; Thu, 02 Jan 2025 07:42:36 -0800
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e4a8b40dd40sf22441636276.3
        for <bitcoindev@gnusha.org>; Thu, 02 Jan 2025 07:42:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1735832548; x=1736437348; 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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=;
        b=FHUGF0Dv8PZBZrbfRrKpDRv0HoHCSKHApOZgcKkMSDi0ZG88DUteCTJxYUm8+4AmJv
         93OzBQRvs3tsiAW/KwYa38qvcczSW2c4F0JDvF+sgI9w9fiiZO1xcFAqm+Ti7vxF2gKD
         i3YQuXh/MTkeTqEytLvHnKYn36VO87JbTrJULPFGFT4NK51pv6KLP3a8K9OyyI0k0L+O
         JO/AlQCozLLF7sku3v5Vf3/gCbKF3ynFPg8HSxd/m51jWxWnyi4/E6PJcysuXW1tFSoz
         Gns8qIUazMWhBU/l2bC1JYmMhvlo9+oexMHkKmIo62h39Z55LiW7dixaJ9cN43e1b8Y9
         mpQA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735832548; x=1736437348; 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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=;
        b=D7e5E2+OP9aeQ7223ni7NBCcajbrQap5gr3ObLM/IvPilYWc2m/H1I+b+p6Eqt8BN5
         e4eMk6rxIxu1zdL9ZUXqGFC8MpDMh/FyDu9ncVQHKgLTF6kthOsgUBHHw8zdIdzbXrmM
         qgkh6a+MQrawqvki9pt1Z6E80wN382DKT2DSU7jhOXPEwMt2fT5oeWs4KKZskJJ+eSxT
         rlGUE/UD69p2N5zXaRM5KHEjic9nNedXcz1SfAGYCULc6vdN8FTxjZk2lgwYE7WiZMHX
         ybbcUHCaeDq8G8jh4baMiahaMaJ/gn5JXSePt4ZEBcTLx0weU1kJUSa5MNA0zqC2rNQy
         i7qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735832548; x=1736437348;
        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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=;
        b=rUW0LdA2cHy2f8CgwZbREKLdMNfAwNa8OFxlOk6GCXJPFFf7OyiwX9XBblggZ09BtC
         nN+c1erCXrMQ+ENicJj7U/ArWXPKptBldPSk9c/A96Z1wRyMz9KTYWZ04824B9RLITza
         Cp8nTS0JliWyhnJN6Bz1sf4gcxr0ey7Un1fAMn5uaIyukjj8FPn6qUMItTKQNKRg/8sk
         12ygc5K9wPZpUu8RFuVaUOT6SOEA4yCCRBtxwxGzhJAoG0Vu56QDkC3wGZvK9wmSqRJE
         HI/E/1jRXkjkD3qIWk0xq28uozTwjIzMz28SCHj/YPsZ3BFbL9z16hvEgE48s0Z3aKea
         ciig==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUQNkpRWjG3wFDeyp4WTI70cVBePSxq3fmBX6Jw7yAaPwGr1oyZGNrEnFglKeXdxpvQEQFh4kR5JFpw@gnusha.org
X-Gm-Message-State: AOJu0YyFBPpjqDDVR04sD/YGZfElfnj/M8QkhS2aJ78ePCayRbxOnMOd
	FD7Glr9SBDhotWjMcBzSwP2iXkT6CMiGEUcbmH1XCZPZ7xb1+449
X-Google-Smtp-Source: AGHT+IH8N+Bop32PEtfw+6UbwN4J7bznLeEg9y3F4HbopimiJDzesjlVoLQeBGDbdfjCMfX9r+oZnQ==
X-Received: by 2002:a25:1f87:0:b0:e3c:a022:b53a with SMTP id 3f1490d57ef6-e538c287c14mr21191019276.28.1735832547851;
        Thu, 02 Jan 2025 07:42:27 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:a1a3:0:b0:e48:8566:cdf0 with SMTP id 3f1490d57ef6-e548058dae3ls64385276.1.-pod-prod-02-us;
 Thu, 02 Jan 2025 07:42:25 -0800 (PST)
X-Received: by 2002:a05:690c:734a:b0:6ef:8dd0:fff9 with SMTP id 00721157ae682-6f3f80d60a5mr331050387b3.8.1735832544973;
        Thu, 02 Jan 2025 07:42:24 -0800 (PST)
Received: by 2002:a05:690c:b10:b0:6ef:9b37:85ef with SMTP id 00721157ae682-6f484ea9c5ams7b3;
        Thu, 2 Jan 2025 07:16:43 -0800 (PST)
X-Received: by 2002:a05:690c:6505:b0:6ef:97a2:49ef with SMTP id 00721157ae682-6f3f80d18f5mr363733247b3.8.1735831001971;
        Thu, 02 Jan 2025 07:16:41 -0800 (PST)
Date: Thu, 2 Jan 2025 07:16:41 -0800 (PST)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <c411dee9-1937-42fd-bc66-d347ddbff506n@googlegroups.com>
In-Reply-To: <BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd27VQfODaemn-jksB8bLFGoM8a70f3xjWI=@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>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1145794_2009645589.1735831001709"
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_1145794_2009645589.1735831001709
Content-Type: multipart/alternative; 
	boundary="----=_Part_1145795_1600931531.1735831001709"

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

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, etc.

I am aware of this and have used the comparison table in my [rationale][1].=
=20
LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.

>  Calling it "unnecessary complexity" is not a valid technical observation=
=20
in any shape or form. It would provide optimization for many contracts and=
=20
use cases even if we had CAT. I explained this to you in private first, yet=
=20
you keep insisting on this completely invalid objection.

It is a valid objection and I find it disappointing that you think people=
=20
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 who=
=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 possible=
=20
with it in bitcoin script and not just the use cases described in your=20
email.

/dev/fd0
floppy disk guy=20

[1]: https://gitlab.com/-/snippets/4777553
[2]: https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ
On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonsettler wro=
te:

> Hi Floppy,
>
> Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. The=
y=20
> make it more efficient, and they also help other contracts.
> Among them: Resumeable LN channels, Multi-party LN channels, Vaults, etc.
>
> Main benefit for the network: we can reduce the number of SigOps on-chain=
=20
> which benefits everyone that runs a validating node by making it more=20
> economic to use a single signature for multiple elements instead of using=
=20
> something like the ReKey technique.
>
> Calling it "unnecessary complexity" is not a valid technical observation=
=20
> in any shape or form. It would provide optimization for many contracts an=
d=20
> use cases even if we had CAT. I explained this to you in private first, y=
et=20
> you keep insisting on this completely invalid objection.
>
> BR,
> moonsettler
>
> PS: I largely agree with everything Ethan said.
>
> Sent with Proton Mail secure email.
>
> On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 <alice...@gmail.com>=
=20
> wrote:
>
> > Hi Ethan,
> > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas=20
> OP_PAIRCOMMIT is a part of LNHANCE.
> >=20
> > In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN=
=20
> SYMMETRY can be achieved with other opcodes.
> >=20
> > Note: The objections shared in this thread are a summarised version of=
=20
> all the rationales and not my person opinion.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth...@gmail.com> wrote:
> >=20
> > > One of the CAT authors here
> > >=20
> > > > > [PAIR_COMMIT] Adds unnecessary complexity
> > > > That's a subjective value judgement it enables something that was n=
o=20
> possible before which is interacting with Merkle trees and multi-element=
=20
> commitments in script. PAIRCOMMIT is not significantly more complicated=
=20
> than CAT, and in a lot of actual use cases CAT was desired for it's more=
=20
> complex and resource intensive to safely use CAT than PAIRCOMMIT due to=
=20
> witness malleability.
> > >=20
> > > PAIR_COMMIT (BIP-442) for all intents and purposes is as simple in
> > > implementation at CAT (BIP-347). I have no technical objection to
> > > PAIRCOMMIT and it provides much needed functionality.
> > >=20
> > > My primary concern is not PAIRCOMMIT itself, but the rationale for=20
> PAIRCOMMIT.
> > >=20
> > > The rationale for PAIRCOMMIT rests on the assumption that the Bitcoin
> > > community does not want the expressiveness of CAT. If we assume this
> > > is the case, then we should be very careful PAIRCOMMIT does not enabl=
e
> > > this expressiveness as well. On the other hand, if the Bitcoin
> > > community does want the expressiveness of CAT, then we should merge
> > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT and i=
t
> > > is likely that you can not simulate CAT with PAIRCOMMIT. That said, I
> > > am not convinced it is impossible that there is no way to simulate CA=
T
> > > with PAIRCOMMIT, nor I do feel confident that I know how much less
> > > powerful PAIRCOMMIT is than CAT.
> > >=20
> > > Playing devil's advocate for a second, if I was opposed to CAT on
> > > grounds that we should limit expressiveness I would want to really
> > > understand the limits of PAIRCOMMIT. For instance can you do arbitrar=
y
> > > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > > why not?
> > >=20
> > > That said, I have not heard any argument against PAIRCOMMIT from thos=
e
> > > against CAT, so perhaps they are comfortable with it.
> > >=20
> > > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.
> > >=20
> > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitcoin Dev=
elopment
> > > Mailing List <bitco...@googlegroups.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > One thing I would like to make clear before people get the wrong=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 means=
.=20
> Literally nobody managed to come up with a single use case anyone worth=
=20
> noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from=
=20
> 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 was n=
o=20
> possible before which is interacting with Merkle trees and multi-element=
=20
> commitments in script. PAIRCOMMIT is not significantly more complicated=
=20
> than CAT, and in a lot of actual use cases CAT was desired for it's more=
=20
> complex and resource intensive to safely use CAT than PAIRCOMMIT due to=
=20
> witness malleability.
> > > >
> > > > > Not convinced it is impossible that there is no way to simulate=
=20
> CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is=
=20
> 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 [mailing=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 definitions fo=
r=20
> '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 rationale.
> > > > >
> > > > > 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 working o=
n=20
> 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 of=20
> multiple covenant proposals.
> > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are=
=20
> not reviewed by enough developers. OP_PARCOMMIT seems to be controversial=
=20
> 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 which i=
s=20
> more efficient. Its not the best option for covenants and cannot be used =
to=20
> improve Ark. Some developers prefer opcodes and not sighash flags.
> > > > >
> > > > > Seems to be the result of an attempt to fix signatures to make=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 tune=
=20
> it to what people are actually using covenants for, instead of prematurel=
y=20
> 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 use=
=20
> 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 Script=
s=20
> if activated alone. Since it happens to enable generic introspection by=
=20
> accident, and therefore an ugly version of state-carrying UTXOs, it=20
> shouldn't be enabled without more ergonomic opcodes for those use 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 relevant=
=20
> 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 in=
=20
> future and added for specific use case. LN SYMMETRY is possible without=
=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 simulate=
=20
> CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is=
=20
> 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 summary=
=20
> and approving edits. There are a few things that I want to share and it=
=20
> could be a result of the aggressive marketing:
> > > > >
> > > > > - A spammer had edited the table to remove all evaluations except=
=20
> in favor of OP_CAT and it was rejected.
> > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention anythin=
g=20
> about other opcodes and SIGHASH_APO. It is only focused on OP_CAT however=
=20
> evaluations exist in the table.
> > > > > - I [requested][7] Udev (CatSwap) to add details about evaluation=
=20
> 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 cells=
.=20
> Although none of them are backed by a rationale so cannot be considered f=
or=20
> consensus discussion. The table is still updated regularly so you may see=
=20
> some of them with a rationale in 2025. Any suggestions to help achieve=20
> 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 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/38a6f252-afe9-4155-a341-11a4=
2a9a9007n%40googlegroups.com
> .
> > > >
> > > > --
> > > > 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,=
=20
> 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
> .
> > >=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, sen=
d=20
> 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 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/=
c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com.

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

Hi moonsettler,<div><br /></div><div>&gt;=C2=A0

Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. They =
make it more efficient, and they also help other contracts.<br />Among them=
: Resumeable LN channels, Multi-party LN channels, Vaults, etc.<br /><br />=
I am aware of this and have used the comparison table in my [rationale][1].=
 LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.<br /><br />&gt;=
=C2=A0

Calling it "unnecessary complexity" is not a valid technical observation in=
 any shape or form. It would provide optimization for many contracts and us=
e cases even if we had CAT. I explained this to you in private first, yet y=
ou keep insisting on this completely invalid objection.<br /><br />It is a =
valid objection and I find it disappointing that you think people will chan=
ge their opinion about an opcode if you build [activation client][2] or a d=
ifferent table. If you read all the rationales, its not just me who finds t=
his opcode irrelevant. Please respect the developers who shared their evalu=
ations in the table even if you disagree with them. If you cannot appreciat=
e efforts to review proposals and reach technical consensus, at least avoid=
 calling reviews/evaluations as "voting".=C2=A0<br /><br />"Unnecessary" be=
cause LN symmetry (efficient) is possible without it. "Complexity" is intro=
duced because it will be used for everything possible with it in bitcoin sc=
ript and not just the use cases described in your email.</div><div><br /></=
div><div>/dev/fd0<br />floppy disk guy=C2=A0<br /><br />[1]:=C2=A0https://g=
itlab.com/-/snippets/4777553<br />[2]:=C2=A0https://groups.google.com/g/bit=
coindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ</div><div class=3D"gmail_quote"><div d=
ir=3D"auto" class=3D"gmail_attr">On Thursday, January 2, 2025 at 7:16:55=E2=
=80=AFPM UTC+5:30 moonsettler wrote:<br/></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;">Hi Floppy,
<br>
<br>Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. T=
hey make it more efficient, and they also help other contracts.
<br>Among them: Resumeable LN channels, Multi-party LN channels, Vaults, et=
c.
<br>
<br>Main benefit for the network: we can reduce the number of SigOps on-cha=
in which benefits everyone that runs a validating node by making it more ec=
onomic to use a single signature for multiple elements instead of using som=
ething like the ReKey technique.
<br>
<br>Calling it &quot;unnecessary complexity&quot; is not a valid technical =
observation in any shape or form. It would provide optimization for many co=
ntracts and use cases even if we had CAT. I explained this to you in privat=
e first, yet you keep insisting on this completely invalid objection.
<br>
<br>BR,
<br>moonsettler
<br>
<br>PS: I largely agree with everything Ethan said.
<br>
<br>Sent with Proton Mail secure email.
<br>
<br>On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 &lt;<a href data-e=
mail-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Hi Ethan,
<br>&gt; OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas=
 OP_PAIRCOMMIT is a part of LNHANCE.
<br>&gt;=20
<br>&gt; In this context, OP_PAIRCOMMIT adds unnecessary complexity because=
 LN SYMMETRY can be achieved with other opcodes.
<br>&gt;=20
<br>&gt; Note: The objections shared in this thread are a summarised versio=
n of all the rationales and not my person opinion.
<br>&gt;=20
<br>&gt; /dev/fd0
<br>&gt; floppy disk guy
<br>&gt;=20
<br>&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;=20
<br>&gt; &gt; One of the CAT authors here
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; &gt; [PAIR_COMMIT] Adds unnecessary complexity
<br>&gt; &gt; &gt; That&#39;s a subjective value judgement it enables somet=
hing that was no possible before which is interacting with Merkle trees and=
 multi-element commitments in script. PAIRCOMMIT is not significantly more =
complicated than CAT, and in a lot of actual use cases CAT was desired for =
it&#39;s more complex and resource intensive to safely use CAT than PAIRCOM=
MIT due to witness malleability.
<br>&gt; &gt;=20
<br>&gt; &gt; PAIR_COMMIT (BIP-442) for all intents and purposes is as simp=
le in
<br>&gt; &gt; implementation at CAT (BIP-347). I have no technical objectio=
n to
<br>&gt; &gt; PAIRCOMMIT and it provides much needed functionality.
<br>&gt; &gt;=20
<br>&gt; &gt; My primary concern is not PAIRCOMMIT itself, but the rational=
e for PAIRCOMMIT.
<br>&gt; &gt;=20
<br>&gt; &gt; The rationale for PAIRCOMMIT rests on the assumption that the=
 Bitcoin
<br>&gt; &gt; community does not want the expressiveness of CAT. If we assu=
me this
<br>&gt; &gt; is the case, then we should be very careful PAIRCOMMIT does n=
ot enable
<br>&gt; &gt; this expressiveness as well. On the other hand, if the Bitcoi=
n
<br>&gt; &gt; community does want the expressiveness of CAT, then we should=
 merge
<br>&gt; &gt; CAT. PAIRCOMMIT is well designed to be less expressive than C=
AT and it
<br>&gt; &gt; is likely that you can not simulate CAT with PAIRCOMMIT. That=
 said, I
<br>&gt; &gt; am not convinced it is impossible that there is no way to sim=
ulate CAT
<br>&gt; &gt; with PAIRCOMMIT, nor I do feel confident that I know how much=
 less
<br>&gt; &gt; powerful PAIRCOMMIT is than CAT.
<br>&gt; &gt;=20
<br>&gt; &gt; Playing devil&#39;s advocate for a second, if I was opposed t=
o CAT on
<br>&gt; &gt; grounds that we should limit expressiveness I would want to r=
eally
<br>&gt; &gt; understand the limits of PAIRCOMMIT. For instance can you do =
arbitrary
<br>&gt; &gt; computation by building STARKs with PAIRCOMMIT merkle trees? =
If not,
<br>&gt; &gt; why not?
<br>&gt; &gt;=20
<br>&gt; &gt; That said, I have not heard any argument against PAIRCOMMIT f=
rom those
<br>&gt; &gt; against CAT, so perhaps they are comfortable with it.
<br>&gt; &gt;=20
<br>&gt; &gt; Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.
<br>&gt; &gt;=20
<br>&gt; &gt; On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM &#39;moonsettler&#39;=
 via Bitcoin Development
<br>&gt; &gt; Mailing List &lt;<a href data-email-masked rel=3D"nofollow">b=
itco...@googlegroups.com</a>&gt; wrote:
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; Hi All,
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; One thing I would like to make clear before people get t=
he wrong idea and think this is some form of voting, OP_INTERNALKEY and OP_=
PARCOMMIT is part of LNhance and will be part of the activation client we r=
elease soon. The only way to change that is to demonstrate actual harm. You=
 liking something else more, is your problem. What you can do about it, is =
write your activation client and try to gain consensus on that. There are p=
lenty of version bits available. Replacing PAIRCOMMIT with CAT would be rea=
lly easy, but while CAT is indeed very popular and has a wide support base =
it is also strongly opposed by many who did not choose to participate. I&#3=
9;m not convinced that this table represents actual developer, let alone ec=
osystem consensus. If you decide you want to run an alternative activation =
effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
<br>&gt; &gt; &gt;
<br>&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; OP_PARCOMMIT
<br>&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;
<br>&gt; &gt; &gt; &gt; OP_PARCOMMIT seems to be controversial at this mome=
nt.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; I strongly disagree. In my book that&#39;s not what cont=
roversial means. Literally nobody managed to come up with a single 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. This BIP is y=
oung, there is a clear correlation between the age of the proposals and the=
ir support with the sole exception of APO.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Adds unnecessary complexity
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; That&#39;s a subjective value judgement it enables somet=
hing that was no possible before which is interacting with Merkle trees and=
 multi-element commitments in script. PAIRCOMMIT is not significantly more =
complicated than CAT, and in a lot of actual use cases CAT was desired for =
it&#39;s more complex and resource intensive to safely use CAT than PAIRCOM=
MIT due to witness malleability.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Not convinced it is impossible that there is no way=
 to simulate CAT with PAIRCOMMIT, nor confident how much less powerful PAIR=
COMMIT is than CAT.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; This is sufficiently addressed in the BIP.
<br>&gt; &gt; &gt;
<br>&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; OP_VAULT
<br>&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;
<br>&gt; &gt; &gt; &gt; No demand for vaults.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; It&#39;s safe to completely ignore that &quot;argument&q=
uot;.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; BR,
<br>&gt; &gt; &gt; moonsettler
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 &l=
t;<a href data-email-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wro=
te:
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Hi Bitcoin Developers,
<br>&gt; &gt; &gt; &gt;
<br>&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 we=
re made based on the feedback:
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; - Removed &#39;community support&#39; from &#39;No&=
#39;. Rephrased definitions for &#39;Prefer&#39; and &#39;Evaluating&#39;.
<br>&gt; &gt; &gt; &gt; - Added LNHANCE category for a combination of opcod=
es.
<br>&gt; &gt; &gt; &gt; - Added links for BIP drafts and a column for &#39;=
rationale&#39;.
<br>&gt; &gt; &gt; &gt; - Created a separate table for evaluations without =
a rationale.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Murch and Gloria shared their feedback in the bitco=
in optech [podcast 333][2]. I have started working on a [page][3] that list=
s use cases, prototype links and primitives used. We can still add more use=
 cases in it. This list does not include use cases enabled by [OP_CHECKSIGF=
ROMSTACK][4] alone or in combination with other opcodes like [LN SYMMETRY][=
5].
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; I had verified each entry to avoid spam and fake ev=
aluations. Rearden was assigned moderator permissions on 8 December 2024 by=
 Theymos to help me with the moderations. Some edits have been approved by =
other moderators.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Some insights from the table that could help develo=
pers working on different covenant proposals:
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; 1. Multiple ways to achieve LN symmetry were discov=
ered. SIGHASH_APO lacks interest among developers, contrary to the belief p=
rior to this exercise.
<br>&gt; &gt; &gt; &gt; 2. OP_CHECKSIGFROMSTACK has unanimous support and i=
s a part of multiple covenant proposals.
<br>&gt; &gt; &gt; &gt; 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRA=
CTVERIFY are not reviewed by enough developers. OP_PARCOMMIT seems to be co=
ntroversial at this moment.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Objections:
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; ```
<br>&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; SIGHASH_APO
<br>&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;
<br>&gt; &gt; &gt; &gt; LN SYMMETRY is possible with combination of a few o=
pcodes which is more efficient. Its not the best option for covenants and c=
annot be used to improve Ark. Some developers prefer opcodes and not sighas=
h flags.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Seems to be the result of an attempt to fix signatu=
res to make them work for a specific use-case, but the end-result is hard-t=
o-reason (for me) and not flexible. In general, SIGHASH flags are an encodi=
ng of specific predicates on the transaction, and I think the Script is bet=
ter suited to carry the predicate. There is no interesting SIGHASH flag tha=
t couldn&#39;t be functionally simulated by introspection + CHECKSIGFROMSTA=
CK (or other Script-based approaches), and that seems to me a much cleaner =
and ergonomic way to achieve the same goals.
<br>&gt; &gt; &gt; &gt;
<br>&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; OP_TXHASH
<br>&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;
<br>&gt; &gt; &gt; &gt; More expressive, many flag configurations, untested=
 and undesirable use cases. Unaddressed comments in the BIP and the delay d=
oesn&#39;t make sense because OP_CHECKTEMPLATEVERIFY can be upgraded later =
to achieve the same thing. Makes hash caching complex, potentially opening =
up DoS vectors or quadratic sighash.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Most templates you&#39;d obtain with various combin=
ations of parameters are meaningless. It implements state-carrying UTXOs in=
 a very dirty way: adding additional inputs/outputs with no other meaning t=
han &quot;storing some state&quot;. This is ugly, inefficient, and bloats t=
he UTXO set - and it definitely will happen if TXHASH is enabled without al=
so enabling a clean way to carry state.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY=
 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;
<br>&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; OP_VAULT
<br>&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;
<br>&gt; &gt; &gt; &gt; No demand for vaults. Customized for a specific use=
 case.
<br>&gt; &gt; &gt; &gt;
<br>&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; OP_CAT
<br>&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;
<br>&gt; &gt; &gt; &gt; Can be used for various complex scripts including u=
ndesirable use cases (DEX, AMM and Hashrate Escrow). Enables granular trans=
action introspection through abuse of schnorr signatures and OP_CHECKSIG. C=
an be used for interesting use cases but alone does it poorly and inefficie=
ntly.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; People can and will litter the chain with inefficie=
nt/ugly Scripts if activated alone. Since it happens to enable generic intr=
ospection by accident, and therefore an ugly version of state-carrying UTXO=
s, it shouldn&#39;t be enabled without more ergonomic opcodes for those use=
 cases.
<br>&gt; &gt; &gt; &gt;
<br>&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; OP_INTERNALKEY
<br>&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;
<br>&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;
<br>&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; OP_PAIRCOMMIT
<br>&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;
<br>&gt; &gt; &gt; &gt; Adds unnecessary complexity, redundant if OP_CAT is=
 activated in future and added for specific use case. LN SYMMETRY is possib=
le without this opcode. It does not compose with anything that involves tra=
nsaction introspection due to its specified tagged hash. Some developers pr=
efer OP_CAT.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Not convinced it is impossible that there is no way=
 to simulate CAT with PAIRCOMMIT, nor confident how much less powerful PAIR=
COMMIT is than CAT.
<br>&gt; &gt; &gt; &gt;
<br>&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; OP_CHECKTEMPLATEVERIFY
<br>&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;
<br>&gt; &gt; &gt; &gt; Limited in scope and not recursive.
<br>&gt; &gt; &gt; &gt; ```
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; I have tried my best to remain unbiased in writing =
this summary and approving edits. There are a few things that I want to sha=
re and it could be a result of the aggressive marketing:
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; - A spammer had edited the table to remove all eval=
uations except in favor of OP_CAT and it was rejected.
<br>&gt; &gt; &gt; &gt; - [Rationale][6] added by Aaron (sCrypt) does not m=
ention anything about other opcodes and SIGHASH_APO. It is only focused on =
OP_CAT however evaluations exist in the table.
<br>&gt; &gt; &gt; &gt; - I [requested][7] Udev (CatSwap) to add details ab=
out evaluation of other opcodes and SIGHASH_APO.
<br>&gt; &gt; &gt; &gt; - Last [edit][8] by Roujiamo (bitdollar) has a rati=
onale with incorrect signet stats and seems to be rephrased version of anot=
her rationale. Evaluation had &#39;weak&#39; for OP_CTV before adding the r=
ationale.
<br>&gt; &gt; &gt; &gt; - An edit with duplicate rationale (in support of O=
P_CAT) was rejected because sharing the link for a rationale submitted by o=
ther developer adds no value in the table.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Evaluations without a rationale have some &#39;No&#=
39; in different cells. Although none of them are backed by a rationale so =
cannot be considered for consensus discussion. The table is still updated r=
egularly so you may see some of them with a rationale in 2025. Any suggesti=
ons to help achieve technical consensus are most welcome.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; What&#39;s next?
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; - More rationales in the table
<br>&gt; &gt; &gt; &gt; - Discuss objections on mailing list (if any)
<br>&gt; &gt; &gt; &gt; - Workshops
<br>&gt; &gt; &gt; &gt; - Add a table for economic nodes and their opinion
<br>&gt; &gt; &gt; &gt; - Build activation client and discuss parameters
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Finally, I would thank all the developers who added=
 their evaluations in the table and everyone who shared updates on twitter.=
 It was a coordinated effort to reach some technical consensus. You can rea=
d all the rationales in detail to understand different perspectives and rea=
sons to support a combination of opcodes over others.
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; [1]: <a href=3D"https://groups.google.com/g/bitcoin=
dev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ" target=3D"_blank" rel=3D"nofollow" data-s=
aferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups=
.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ&amp;source=3Dgmail&am=
p;ust=3D1735916377158000&amp;usg=3DAOvVaw3Fj1cWEQXk2WEhCy3G06eW">https://gr=
oups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ</a>
<br>&gt; &gt; &gt; &gt; [2]: <a href=3D"https://bitcoinops.org/en/podcast/2=
024/12/17/" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Den&amp;q=3Dhttps://bitcoinops.org/en/podcast/20=
24/12/17/&amp;source=3Dgmail&amp;ust=3D1735916377158000&amp;usg=3DAOvVaw3Ep=
_bWSqMF00jpGPci6_CQ">https://bitcoinops.org/en/podcast/2024/12/17/</a>
<br>&gt; &gt; &gt; &gt; [3]: <a href=3D"https://en.bitcoin.it/wiki/Covenant=
s_Uses" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://=
www.google.com/url?hl=3Den&amp;q=3Dhttps://en.bitcoin.it/wiki/Covenants_Use=
s&amp;source=3Dgmail&amp;ust=3D1735916377158000&amp;usg=3DAOvVaw1FHjwGG0br2=
onYc3IriGFX">https://en.bitcoin.it/wiki/Covenants_Uses</a>
<br>&gt; &gt; &gt; &gt; [4]: <a href=3D"https://github.com/bitcoin/bips/blo=
b/master/bip-0348.md" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin=
/bips/blob/master/bip-0348.md&amp;source=3Dgmail&amp;ust=3D1735916377158000=
&amp;usg=3DAOvVaw3QXRJSDlQRdQTKOdaRgHsF">https://github.com/bitcoin/bips/bl=
ob/master/bip-0348.md</a>
<br>&gt; &gt; &gt; &gt; [5]: <a href=3D"https://gist.github.com/Ademan/4a14=
614fa850511d63a5b2a9b5104cb7" target=3D"_blank" rel=3D"nofollow" data-safer=
edirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.githu=
b.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7&amp;source=3Dgmail&amp;ust=3D=
1735916377158000&amp;usg=3DAOvVaw1g8MLObTadirbheQEoadjC">https://gist.githu=
b.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7</a>
<br>&gt; &gt; &gt; &gt; [6]: <a href=3D"https://gist.github.com/gitzhou/dc9=
2c41db1987db16fe665c26bc56dd9" target=3D"_blank" rel=3D"nofollow" data-safe=
redirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.gith=
ub.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9&amp;source=3Dgmail&amp;ust=
=3D1735916377158000&amp;usg=3DAOvVaw0xjszab8Yaqhrww6pg_lWL">https://gist.gi=
thub.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9</a>
<br>&gt; &gt; &gt; &gt; [7]: <a href=3D"https://gist.github.com/udevswap/b7=
68d20d62549922b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5=
359072" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://=
www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.github.com/udevswap/b768d20=
d62549922b9e72428ef9eb608?permalink_comment_id%3D5359072%23gistcomment-5359=
072&amp;source=3Dgmail&amp;ust=3D1735916377158000&amp;usg=3DAOvVaw2jmwLch6h=
qxYY2q-ORl4_-">https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9=
eb608?permalink_comment_id=3D5359072#gistcomment-5359072</a>
<br>&gt; &gt; &gt; &gt; [8]: <a href=3D"https://en.bitcoin.it/w/index.php?t=
itle=3DCovenants_support&amp;diff=3Dprev&amp;oldid=3D70520" target=3D"_blan=
k" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://en.bitcoin.it/w/index.php?title%3DCovenants_support%2=
6diff%3Dprev%26oldid%3D70520&amp;source=3Dgmail&amp;ust=3D1735916377158000&=
amp;usg=3DAOvVaw2fy27SYzHkyOpMKym18l-F">https://en.bitcoin.it/w/index.php?t=
itle=3DCovenants_support&amp;diff=3Dprev&amp;oldid=3D70520</a>
<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; /dev/fd0
<br>&gt; &gt; &gt; &gt; floppy disk guy
<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/38a6f252-afe9-4155-a341-11a42a9a9007n%40=
googlegroups.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/38a6f252-afe9-4155-a341-11a42a9a9007n%2540googlegroups.com=
&amp;source=3Dgmail&amp;ust=3D1735916377158000&amp;usg=3DAOvVaw1YtHVvNQlzEp=
7f-xClnf6J">https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155=
-a341-11a42a9a9007n%40googlegroups.com</a>.
<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; --
<br>&gt; &gt; &gt; You received this message because you are subscribed to =
the Google Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; &gt; &gt; To unsubscribe from this group and stop receiving emails=
 from it, send an email to <a href data-email-masked rel=3D"nofollow">bitco=
indev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; To view this discussion visit <a href=3D"https://groups.=
google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG1=
01_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonm=
ail.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/bitco=
indev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-Q=
zfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%253D%2540protonmail.com&amp;source=
=3Dgmail&amp;ust=3D1735916377158000&amp;usg=3DAOvVaw27cTk1rOI09etHqIY1BcV8"=
>https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcu=
QktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBW=
Xac%3D%40protonmail.com</a>.
<br>&gt; &gt;=20
<br>&gt; &gt; --
<br>&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; &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; &gt; To view this discussion visit <a href=3D"https://groups.googl=
e.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xj=
Aa7DBaA%40mail.gmail.com" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.=
com/d/msgid/bitcoindev/CAEM%253Dy%252BV9Gu0n7pLv1d%252BK1HfaFsB3kXg-LbtppyZ=
G0xjAa7DBaA%2540mail.gmail.com&amp;source=3Dgmail&amp;ust=3D173591637715800=
0&amp;usg=3DAOvVaw0qV-9McH-a6mJelyKr2rBf">https://groups.google.com/d/msgid=
/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mai=
l.gmail.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/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com</a>.<br />

------=_Part_1145795_1600931531.1735831001709--

------=_Part_1145794_2009645589.1735831001709--