path: root/f2/c5517440c564145299020d0d30c846a1b26f10

Delivery-date: Thu, 02 Jan 2025 05:47:03 -0800
Received: from mail-qv1-f57.google.com ([209.85.219.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBTFR3K5QMGQE3CPA7IA@googlegroups.com>)
	id 1tTLXS-0006kt-3n
	for bitcoindev@gnusha.org; Thu, 02 Jan 2025 05:47:03 -0800
Received: by mail-qv1-f57.google.com with SMTP id 6a1803df08f44-6d88d56beb7sf113033926d6.3
        for <bitcoindev@gnusha.org>; Thu, 02 Jan 2025 05:47:01 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1735825615; cv=pass;
        d=google.com; s=arc-20240605;
        b=Q/pFVzffCRSlQb12QJEBu1GQZRozSaaQqsyYrk++3bI8AP9gLa9oG7IJsX8bQ4tCUu
         4BtJ/yWLdDGoTNISF4miOtEa3A9g9a3NSHQLucad7qV92Hl3x4Eej1sMQNoCPriQV+Nq
         X49Uq5PnPzELWpf+kn2rcuUuFnSXWuWGAaW/upuCFtU/D47wac0cLvfxm3z9uJFymFYm
         1oMIGeZ2ulsQh9x0KyJ+X7BFk0iM5Krfgj97TkX5CfTpbKYz6/0N5kYTqcDtcd+NNex+
         HDo6bEav3eDxnizwRhc035itZ7GJgS4R5TR5nsjNwQMEnYziSSHmgcu1Gz+CXG3leAi5
         OrWA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:content-transfer-encoding
         :mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=;
        fh=ck+ntOCCaNxBMXvhI6A5briUYihahcC1/dd5SEYFqr4=;
        b=IeKDcKOMve09xZk8+HfNJ9KYEpKrMG2LTHz5HSYyPl3IZyx5Hc1qC27fj1kekS08R9
         zGsTXt+Hgu+WyInZMh6ZtsjFuua39lTCfcpvq+mhM6cDOz52r2k0Bw1QVhtFhr25c+hl
         E4E5qePo1b3FAojzlR3zGIS/7J08208Pyvl1LBmmhvkXaESXI2kq3z7x4z4gPxTrY+L/
         iWU/6WfGyHw+ia8Jv09ZQj9YoBaXoNPUuBIR5yY48Q8HaVwJEjHUIZOrRR1RmZbVSL2r
         eEorfJCPaEL1G0I5E4/5uXpqMneT7pERFhPHP1O8V/8hagIOcBB2JIpQU8SXX/bGtHhk
         UeGQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7";
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1735825615; x=1736430415; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender
         :content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject
         :date:message-id:reply-to;
        bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=;
        b=S1zmMU3solEqC7F9BN9C7RTOHtXXupuVontRnhY/Fp/+ktuNwyDzw/ywsTFTRhfJKs
         Y6/loJJN6cLDBvNk3E6lWR7Ypk+lgXX0sNwu4DzkYQN7Aa7ONua3MlaMrpu/fkPwxGwV
         PdXzBRscDmJIghXyYriB9VfCIChGSepydadmO57vRz2FhjekGcsxffiufCw6hTQpbc5r
         beRQo5nXCNYNoo7TZAKMnhOa0TnO6LzGHWAexO8F3K0K2dHHjBZZI38IPxlNUDN5xXIl
         q+ti10bFeQGD5LniYmnb9LQRQTQf+rU+8bNg4cJ0akmWZlvwjGKwN7n1Cx8MIo+P7v3B
         WBGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735825615; x=1736430415;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender
         :content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=;
        b=H+ilxBQ+NTreEgrQXPwF3PmE5FYwobcgGLOpGwAmvRZSZ/VLRoSepmkU9AVnkAWUMw
         Qlo1zVWLtv2u2jO4NyVBBqM3Yd+bnrAliiM5j6TCkRt4I0UNDOuFLkZ8ByjJF3hdOohO
         LZ8/gOvqVG2pxYZLFbBksPJ26C9anATdMuq8ZjdkLML9XxXbg0DN8/STdPs7Gt08KVaZ
         9erbgGL8PfELBHvf9DeyrQZGjJDVRN+5jgbt8A26ane5An+bBQcdSBuqBeggewxqkdZy
         1IEC43M3Ux58+8fnh3rTa7ehM1XjcYFe24FLQFqGULiMoSolcPCKv6P4Q0coKixW0xjk
         VOCw==
X-Forwarded-Encrypted: i=2; AJvYcCVYiQ0hMTjEbeEEp437rKm00pW18BV3esC9YjBl6CNLsSMUFNM4A3ng1xyVrWoiiSdPWMolaqeTiBnf@gnusha.org
X-Gm-Message-State: AOJu0Yy32vUnYD4XfDmhWMHOH2ttlXmQ65c59N8Gw5aFzMDzDi79vLyE
	/+f7EaFAm/PZAX9sEu6qG/dxA1TnqI79j0sTi5pSyxSa61Lot+6o
X-Google-Smtp-Source: AGHT+IHOhbixIIXQ3RVqrqN6iH2HkSjcFL/1eaf76mOE3GnLyc12InEkt6T+EcAzXkeD9Zj5nvhTdg==
X-Received: by 2002:a05:6214:486:b0:6d8:b594:c590 with SMTP id 6a1803df08f44-6dd23307cacmr638122976d6.6.1735825615369;
        Thu, 02 Jan 2025 05:46:55 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:598b:b0:6d8:f050:cdf8 with SMTP id
 6a1803df08f44-6dd15486c4els27058286d6.1.-pod-prod-08-us; Thu, 02 Jan 2025
 05:46:52 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXMFE1wAMmeJXYID51EsQfKaebuxjxM/5gOcHjcPUsDh066tNS8ACaW2UFA2kmKhe67kJUqmv8s5NiH@googlegroups.com
X-Received: by 2002:a05:620a:4141:b0:7b6:d079:7496 with SMTP id af79cd13be357-7b9ba7e60aamr6309032585a.46.1735825612404;
        Thu, 02 Jan 2025 05:46:52 -0800 (PST)
Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14fms85a;
        Thu, 2 Jan 2025 05:40:51 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXCT/Xb/NXC25tI2gT0m3+n/bobAtgblAGJG3gVIuU6Szl/ixEkoY5KR3N591tefrs8jmlsxIZq2gvK@googlegroups.com
X-Received: by 2002:a05:651c:2209:b0:300:1de5:59e3 with SMTP id 38308e7fff4ca-304685173c8mr126658301fa.2.1735825249453;
        Thu, 02 Jan 2025 05:40:49 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1735825249; cv=none;
        d=google.com; s=arc-20240605;
        b=BFJGHL5QNt8QOum7n5lsVJAn55Rph22K/UV3hlkjRYRlcswx1vVLNc9eDJuWy2hBsf
         y42f8CdQ2r/8/lDdO8Gsr0KNvoUhh2yuKp0XEZajwofJtLTN0mXe6oBQ9CExsKkLBMYc
         vuZCduv6TvEN87CgoYrD1dWoT6JzpqPDLyC1z1Gwb1U8od/DOh6bIg2Uhj7Y2Wxyx1eR
         VZ4dcH48CGObLcI/DDs7MlrSO8sUB9RVwJiSgrePRr8ZxI1RVPOS+ZSuljvzVkjJOkJY
         UDPdTZVPrXFowIHHYouwXDwBiU/Lb24hTb2J30f4NNFBplQ0gD4cPONpB8JBkEBk8zxh
         Lz5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature;
        bh=+28aClvOIL+tnp/AKLXiSKNXWi/1oPzdstXP1jIodT0=;
        fh=otp8siENmaEy3fGyFfzSjl5yvOyG7SrLkx37VM0SK0s=;
        b=ZbvV4zoLOiv60WSBpMFU/MA27hLr94Tx8Ykv/x7VNCsElAKHTssE/dJtHJKhy8yNO5
         UdhbPvLZY/2Buhg9mWkxVzY5yOQGG+D482eSHwRr9NcBQgm8fEa5XTrjGv/MpsARimNm
         +kzD5029eKHO4YwAFHxCT0qD9eYNaO4N4nuEUbt04+Of3gtAFB4u//XgfvJ1EKllo5Av
         vlrHUSwqv33qq70TMYz03qZLEgD2qNbt3kp8l+/BIb09M1inVPr4PmTKKphqNLj3EyKO
         kG6Et201le7fYECH1Q6V2Y4blbLNd7rmCjDPDiphhLNmmg2ZeZ6dB1YYFh8FZSJE9UYq
         BrOA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7";
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch. [79.135.106.101])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3045ae02e91si4464791fa.3.2025.01.02.05.40.49
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 02 Jan 2025 05:40:49 -0800 (PST)
Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) client-ip=79.135.106.101;
Date: Thu, 02 Jan 2025 13:40:43 +0000
To: /dev /fd0 <alicexbtong@gmail.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Ethan Heilman <eth3rs@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
Message-ID: <BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd27VQfODaemn-jksB8bLFGoM8a70f3xjWI=@protonmail.com>
In-Reply-To: <CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA@mail.gmail.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>
Feedback-ID: 38540639:user:proton
X-Pm-Message-ID: 60da296a4f50d5f6f9dd8cfdff55e878fa6ab64a
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: moonsettler@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7";
       spf=pass (google.com: domain of moonsettler@protonmail.com designates
 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: moonsettler <moonsettler@protonmail.com>
Reply-To: moonsettler <moonsettler@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

Hi Floppy,

Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. They =
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 w=
hich benefits everyone that runs a validating node by making it more econom=
ic to use a single signature for multiple elements instead of using somethi=
ng like the ReKey technique.

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,
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 <alicexbtong@gmail.com=
> wrote:

> Hi Ethan,
> OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAI=
RCOMMIT is a part of LNHANCE.
>=20
> In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN SYM=
METRY can be achieved with other opcodes.
>=20
> Note: The objections shared in this thread are a summarised version of al=
l the rationales and not my person opinion.
>=20
> /dev/fd0
> floppy disk guy
>=20
> On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth3rs@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 no =
possible before which is interacting with Merkle trees and multi-element co=
mmitments in script. PAIRCOMMIT is not significantly more complicated than =
CAT, and in a lot of actual use cases CAT was desired for it's more complex=
 and resource intensive to safely use CAT than PAIRCOMMIT due to witness ma=
lleability.
> >=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 PAIR=
COMMIT.
> >=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 enable
> > 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 it
> > 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 CAT
> > 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 arbitrary
> > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > why not?
> >=20
> > That said, I have not heard any argument against PAIRCOMMIT from those
> > 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 Devel=
opment
> > Mailing List <bitcoindev@googlegroups.com> wrote:
> > >
> > > Hi All,
> > >
> > > One thing I would like to make clear before people get the 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 release soon. =
The only way to change that is to demonstrate actual harm. You liking somet=
hing else more, is your problem. What you can do about it, is write your ac=
tivation client and try to gain consensus on that. There are plenty of vers=
ion bits available. Replacing PAIRCOMMIT with CAT would be really easy, but=
 while CAT is indeed very popular and has a wide support base it is also st=
rongly opposed by many who did not choose to participate. I'm not convinced=
 that this table represents actual developer, let alone ecosystem consensus=
. If you decide you want to run an alternative activation effort with CAT i=
nstead 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. =
Literally nobody managed to come up with a single use case anyone worth not=
ing objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those =
that prefer CAT as plain trolling. This BIP is young, there is a clear corr=
elation between the age of the proposals and their support with the sole ex=
ception of APO.
> > >
> > > > Adds unnecessary complexity
> > >
> > > That's a subjective value judgement it enables something that was no =
possible before which is interacting with Merkle trees and multi-element co=
mmitments in script. PAIRCOMMIT is not significantly more complicated than =
CAT, and in a lot of actual use cases CAT was desired for it's more complex=
 and resource intensive to safely use CAT than PAIRCOMMIT due to witness ma=
lleability.
> > >
> > > > Not convinced it is impossible that there is no way to simulate CAT=
 with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than C=
AT.
> > >
> > > 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 <alicexbtong@gm=
ail.com> wrote:
> > >
> > > > Hi Bitcoin Developers,
> > > >
> > > > 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:
> > > >
> > > > - Removed 'community support' from 'No'. Rephrased definitions 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 rationale.
> > > >
> > > > Murch and Gloria shared their feedback in the bitcoin optech [podca=
st 333][2]. I have started working on a [page][3] that lists use cases, pro=
totype links and primitives used. We can still add more use cases in it. Th=
is list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] alo=
ne or in combination with other opcodes like [LN SYMMETRY][5].
> > > >
> > > > I had verified each entry to avoid spam and fake evaluations. Reard=
en was assigned moderator permissions on 8 December 2024 by Theymos to help=
 me with the moderations. Some edits have been approved by other moderators=
.
> > > >
> > > > Some insights from the table that could help developers working on =
different covenant proposals:
> > > >
> > > > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_AP=
O lacks interest among developers, contrary to the belief prior to this exe=
rcise.
> > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mult=
iple covenant proposals.
> > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not=
 reviewed by enough developers. OP_PARCOMMIT seems to be controversial at t=
his 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 is =
more efficient. Its not the best option for covenants and cannot be used to=
 improve Ark. Some developers prefer opcodes and not sighash flags.
> > > >
> > > > Seems to be the result of an attempt to fix 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 p=
redicates on the transaction, and I think the Script is better suited to ca=
rry the predicate. There is no interesting SIGHASH flag that couldn't be fu=
nctionally simulated by introspection + CHECKSIGFROMSTACK (or other Script-=
based approaches), and that seems to me a much cleaner and 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 undesirable=
 use cases. Unaddressed comments in the BIP and the delay doesn't make sens=
e because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same =
thing. Makes hash caching complex, potentially opening up DoS vectors or qu=
adratic sighash.
> > > >
> > > > Most templates you'd obtain with various combinations of parameters=
 are meaningless. It implements state-carrying UTXOs in a very dirty way: a=
dding additional inputs/outputs with no other meaning than "storing some st=
ate". This is ugly, inefficient, and bloats the UTXO set - and it definitel=
y will happen if TXHASH is enabled without also enabling a clean way to car=
ry state.
> > > >
> > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune i=
t to what people are actually using covenants for, instead of prematurely o=
ptimizing 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 c=
ases (DEX, AMM and Hashrate Escrow). Enables granular transaction introspec=
tion through abuse of schnorr signatures and OP_CHECKSIG. Can be used for i=
nteresting use cases but alone does it poorly and inefficiently.
> > > >
> > > > People can and will litter the chain with inefficient/ugly Scripts =
if activated alone. Since it happens to enable generic introspection by acc=
ident, and therefore an ugly version of state-carrying UTXOs, it 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 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 fu=
ture and added for specific use case. LN SYMMETRY is possible without this =
opcode. It does not compose with anything that involves transaction introsp=
ection due to its specified tagged hash. Some developers prefer OP_CAT.
> > > >
> > > > Not convinced it is impossible that there is no way to simulate CAT=
 with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than C=
AT.
> > > >
> > > > =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 and=
 approving edits. There are a few things that I want to share and it could =
be a result of the aggressive marketing:
> > > >
> > > > - A spammer had edited the table to remove all evaluations except i=
n favor of OP_CAT and it was rejected.
> > > > - [Rationale][6] added by Aaron (sCrypt) does not mention anything =
about other opcodes and SIGHASH_APO. It is only focused on OP_CAT however e=
valuations exist in the table.
> > > > - I [requested][7] Udev (CatSwap) to add details about evaluation o=
f other opcodes and SIGHASH_APO.
> > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incor=
rect signet stats and seems to be rephrased version of another rationale. E=
valuation had 'weak' for OP_CTV before adding the rationale.
> > > > - An edit with duplicate rationale (in support of OP_CAT) was rejec=
ted because sharing the link for a rationale submitted by other developer a=
dds no value in the table.
> > > >
> > > > Evaluations without a rationale have some 'No' in different cells. =
Although none of them are backed by a rationale 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. Any suggestions to help achieve tech=
nical 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 evaluatio=
ns in the table and everyone who shared updates on twitter. It was a coordi=
nated effort to reach some technical consensus. You can read all the ration=
ales in detail to understand different perspectives and reasons to support =
a combination of opcodes over others.
> > > >
> > > > [1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2=
IAQAJ
> > > > [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]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb=
7
> > > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56d=
d9
> > > > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb=
608?permalink_comment_id=3D5359072#gistcomment-5359072
> > > > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_support&di=
ff=3Dprev&oldid=3D70520
> > > >
> > > > /dev/fd0
> > > > floppy disk guy
> > > >
> > > > --
> > > > 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, s=
end an email to bitcoindev+unsubscribe@googlegroups.com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bit=
coindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com.
> > >
> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+unsubscribe@googlegroups.com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-Q=
zfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com.
> >=20
> > --
> > You received this message because you are subscribed to the Google Grou=
ps "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send =
an email to bitcoindev+unsubscribe@googlegroups.com.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoin=
dev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-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/=
BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd2=
7VQfODaemn-jksB8bLFGoM8a70f3xjWI%3D%40protonmail.com.