path: root/cc/314a778ffcb5826a727c649382a95058269340

Delivery-date: Wed, 01 Jan 2025 10:19:57 -0800
Received: from mail-qv1-f61.google.com ([209.85.219.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRBQ4O225QMGQEDKW7W6A@googlegroups.com>)
	id 1tT3K0-0007De-BN
	for bitcoindev@gnusha.org; Wed, 01 Jan 2025 10:19:57 -0800
Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6d92f0737besf154590076d6.1
        for <bitcoindev@gnusha.org>; Wed, 01 Jan 2025 10:19:55 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1735755590; cv=pass;
        d=google.com; s=arc-20240605;
        b=HkB+CmpuUitOIJonYqMjICK94pVtQXugWMlRUfVJuHdMZL4Lh3bBeZhHUdLSbG4E/b
         1ASnQEsCAsu2S45pD5pUbuxvGL2ILVc/8ydtRWaaydBRq+kezGrYSTJ4OrDRuTE7DmZw
         CUvxz/UyH1WFfwqhEEupvGk/jgkXymyNihqB21HlyAuNKfukSaUOe0CGXW757/aapLxy
         5APbM7dbw/91fnmTLNQh1QI8E3gIEQE/qsS2nJCM7cVGGIAQRDifjmifErxDJnCgM2RG
         HQ4q69VA5XCtbrds/9QGWhcwrkpOvk2oiYJr2YpDyemh4NtoYucco5dQ51Kl6chzk3Ce
         UYYg==
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:content-transfer-encoding:cc:to
         :subject:message-id:date:from:in-reply-to:references:mime-version
         :sender:dkim-signature:dkim-signature;
        bh=XJPgVdDbt7K0k98sUydZh04efsEc9KmsDb35MbTxV/g=;
        fh=W/EXZN7hhiyGCekcV6TSRJd2KL+6PUIUwTMkKOKQ24c=;
        b=hMlMryEF46k7EokSiGoNR7whg6fKkzH9hlmwJv1OWbpoE15CdHNqCPIXLUqfPd6YAw
         fPW5sGd7cj4yhj/J/TkSr2Ww4WIkAVNPrlVLkigdhhC7h9DoSW8GWfragVbyQ7ETG3vp
         6b1OuaFQgqgjFeoeSSd9VbJNHV6wHZQyZD8MSfErv1+sKAU4wCF+E5RcrDRmpycLmRY6
         gyQW6IT2q1HfNAIpJPLiEQNe+SEfxS1enngbDN02d3hGt2xzNRZatG9n5ZEdoUOeijLF
         fO9Qcunhn94RZfeeFAjfGIN5KVQiJTOrQCw0wmHxhqEN/ramxetw+zIgy8qZfjO8jeE5
         E05Q==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=lB0skkTh;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1735755590; x=1736360390; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XJPgVdDbt7K0k98sUydZh04efsEc9KmsDb35MbTxV/g=;
        b=VKjRGQKjE/Le64NBrXMb9IdS00gHoK//BKZPgYJWaILZs/F+I4qWBI3NP3TPYvPmWD
         6rnW2RCL8JCgM13iPwfpJnlS7DXwdwpD12mwDEkrkd8IAHeZK2XAl58utC39WPwYcD1t
         soSXjG/EVqfCgbzk9DxFBgthEMXIQvHt78V1ZJNeEFSq/Pln7QP5Vtn0+SsZhb8vLxha
         oMhCC5vxKo4iedkyWdJiEhUCjmzJlx1TTicbQ6a7zhR0G2e6ttxZwzLpTJYxkP1I8MNj
         eRdaoTQForiBxpwD28joT0Ys/9zMhgAr1FtLv4Ry/eTUWhKkO8VrBfExFjeVok6Ikx4k
         Y3sQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735755590; x=1736360390; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XJPgVdDbt7K0k98sUydZh04efsEc9KmsDb35MbTxV/g=;
        b=b//Wb41pAHZLg/F1AnDGm5XUGkLIm2OEnPGjEdjsj6GBXgr1oFhtx5/7cytVu3E5Yy
         +PtVnFGGroVGxkc9Op0WdR8rbWSBfoEIN4KBHn+etqfq2i4NY7DuvO8wezprqzn4DKtg
         iLQYY/IFa/d5LbKRZgTwVveV9T5959lJaAvKADejKKbIXHAlE1EnhnP6O0UYeE9PNIBU
         lLh1Cw3CUiSfTaSkgvsJqi72hDcqL6r6OkyDhMEgtDrLAq8/yI8BTYdJFh3NcqzBbJ4F
         poWh9G7hXgBBFO2BPDBBsjDAPH+rMzUc7lo99mFTSH8t2P9E/CSLfxT5+O4IH6/qHRfg
         2D9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735755590; x=1736360390;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XJPgVdDbt7K0k98sUydZh04efsEc9KmsDb35MbTxV/g=;
        b=YTYsMYHfJ4/mLCLE43PtQvAv3bcQaRB0SVHq4sN7RqvAhduiPchQ1FQq7APGusBFiz
         sqA4+ZlePqlhuoG8Alrc7vpU8yejJ67uBPMxzZE1lfkWBGIoMun89K2y05jI2B/NGLr7
         S2jMdWu46v1ygNpmdH2R4prV11nOpy35jwN9C/BFw2AZ2myVtyApr9wI/DXTo9Ohc8pK
         c8B5VUGsPiMx7fOCLpsqa4o2MslXkNjLBwZHDVsQ/MEYWR3I7Oz/yxATL9Ro205QnYp4
         9K91KRHVyddsHLaKNBm6j09oDDtXIGhMI3viyKaR5Qjhb1DSgZjf7+KspuS+Eyo6e+HA
         KD5Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVcJ8VcwWpJB7ZmvMJV3s8j59B9Ml7GTCNav46PqcU6KT2jtmO24jDxSfj/ygmxW2gdbCRKcMKBFy4n@gnusha.org
X-Gm-Message-State: AOJu0YwwTiE5tZI+aDBTWEoXZCi3K0LhUUBOGaxyxz2Uu1dU7clheFHc
	GABl2SXJitRwZYIkMvmPfIywOauqtpFeV1/avLg+nyBCD40uH4pz
X-Google-Smtp-Source: AGHT+IH8JB1cWwuKr48OIi1C7ghMttGaQsMC67nyxYU/0Q2QjIFWbSbO4+3kD4CH1UykwkeF+ZwvEA==
X-Received: by 2002:ad4:5d67:0:b0:6d8:a570:faee with SMTP id 6a1803df08f44-6dd233462b1mr795398216d6.16.1735755589565;
        Wed, 01 Jan 2025 10:19:49 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ac8:7d14:0:b0:466:b34c:880d with SMTP id d75a77b69052e-46a3b07580dls13651861cf.0.-pod-prod-03-us;
 Wed, 01 Jan 2025 10:19:46 -0800 (PST)
X-Received: by 2002:a05:620a:2907:b0:7b7:142d:53b8 with SMTP id af79cd13be357-7b9ba838cc8mr6394000685a.53.1735755586781;
        Wed, 01 Jan 2025 10:19:46 -0800 (PST)
Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14ems85a;
        Wed, 1 Jan 2025 10:12:11 -0800 (PST)
X-Received: by 2002:a05:600c:468a:b0:434:fb8b:deee with SMTP id 5b1f17b1804b1-43669a31484mr320236655e9.16.1735755129697;
        Wed, 01 Jan 2025 10:12:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1735755129; cv=none;
        d=google.com; s=arc-20240605;
        b=UDglh5PV3l62vQr5H47LeZmkXTS87itz+GA9taJprKbEV3iUKlXGyFXRkB4GvovgL/
         bHUrNifHiZpCvp9XLi3Zv26dlEXnAPU0AP5aUNd5Ao9gVUQxPeRIv41BIpwC8fz9U9y8
         TjFoQC/dd0H8zhxt73dMvSxnKdmq/ROElCjJSAtqhXc8vPK/CcfTh9nRAx+POlbsUvbd
         7R53qhOZOvgvOA0QhuJYhF5V+dS6VzymXpn1J47jozwM0wq75+sUVYCYNoHSC6S7KMXa
         0GsmUPUcXtAEI50sLarGeJ0PvknBalzVDu4B+k/kDuGLH51FPLtkncMzcPjxMMxRLJLt
         v6Tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=isu9fvgGbjs1w/LbDmA47kIhmsMA9SioI8jp1jNJ+kE=;
        fh=QY5L8tL49i3fI06Bz5MX5IUm+Byyfp6LTijCthLNvdI=;
        b=WJggUlNzgC/U7gGCDCac3Z4Gn3iA/JEWB969CLc1qAsxEuTKPN16cXEsn/9iPLdINp
         u9VsEYNrDYDgluF5rJwC/ATlbnMGccn0fTKnM0BzOgQ67yTwLnpmUMTJSkRClQRmW0Y1
         66p2XskUsUUGNBZ72OicVQrzAw5JzqtdxbRo6BmOLeckSDEjUr6z6VTK0H9235dGt+Hw
         NLOKqxK1MZjCTSgKCtnVrp++xi/Q3X7CdgoUXs9vloTthXWKw9Fv/r5e6i2/Xt5jWo/q
         o0W87eHb9lBpasaXxY6nzgxpduK5hTpIfJkv4FJ9nOhoedDgWhuccUhigLNCUh99FHKE
         ND7g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=lB0skkTh;
       spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com. [2a00:1450:4864:20::62e])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4368eaa584fsi10965345e9.0.2025.01.01.10.12.09
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 01 Jan 2025 10:12:09 -0800 (PST)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) client-ip=2a00:1450:4864:20::62e;
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aabfb33aff8so1881887366b.0
        for <bitcoindev@googlegroups.com>; Wed, 01 Jan 2025 10:12:09 -0800 (PST)
X-Gm-Gg: ASbGncu6si1CsEm26/m/jZHcu7HXVa3D/BfUyqXU/lmfe9GR1mrnC4keHE13ji8f41C
	BRTOAPHarCgpY1uj7HrAAdwFZyRBSuL5LsPHkoA==
X-Received: by 2002:a17:907:1b83:b0:aae:cf50:5605 with SMTP id
 a640c23a62f3a-aaecf50562bmr2256767066b.19.1735755128654; Wed, 01 Jan 2025
 10:12:08 -0800 (PST)
MIME-Version: 1.0
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
In-Reply-To: <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Wed, 1 Jan 2025 13:11:31 -0500
Message-ID: <CAEM=y+V9Gu0n7pLv1d+K1HfaFsB3kXg-LbtppyZG0xjAa7DBaA@mail.gmail.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
To: moonsettler <moonsettler@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: eth3rs@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=lB0skkTh;       spf=pass
 (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::62e as
 permitted sender) smtp.mailfrom=eth3rs@gmail.com;       dmarc=pass (p=NONE
 sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <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 (/)

One of the CAT authors here

> > [PAIR_COMMIT] Adds unnecessary complexity
> That's a subjective value judgement it enables something that was no poss=
ible before which is interacting with Merkle trees and multi-element commit=
ments 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 mallea=
bility.

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.

My primary concern is not PAIRCOMMIT itself, but the rationale for PAIRCOMM=
IT.

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.

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?

That said, I have not heard any argument against PAIRCOMMIT from 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 Developme=
nt
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 something=
 else more, is your problem. What you can do about it, is write your activa=
tion client and try to gain consensus on that. There are plenty of version =
bits available. Replacing PAIRCOMMIT with CAT would be really easy, but whi=
le CAT is indeed very popular and has a wide support base it is also strong=
ly opposed by many who did not choose to participate. I'm not convinced tha=
t this table represents actual developer, let alone ecosystem consensus. If=
 you decide you want to run an alternative activation effort with CAT inste=
ad 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. Lite=
rally nobody managed to come up with a single use case anyone worth noting =
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 correlat=
ion between the age of the proposals and their support with the sole except=
ion of APO.
>
> > Adds unnecessary complexity
>
> That's a subjective value judgement it enables something that was no poss=
ible before which is interacting with Merkle trees and multi-element commit=
ments 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 mallea=
bility.
>
> > Not convinced it is impossible that there is no way to simulate CAT wit=
h PAIRCOMMIT, nor confident how much less powerful 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 <alicexbtong@gmail.=
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 'Pre=
fer' 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 [podcast 3=
33][2]. I have started working on a [page][3] that lists use cases, prototy=
pe links and primitives used. We can still add more use cases in it. This l=
ist does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] alone o=
r in combination with other opcodes like [LN SYMMETRY][5].
> >
> > I had verified each entry to avoid spam and fake evaluations. Rearden w=
as 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 diff=
erent covenant proposals:
> >
> > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO la=
cks interest among developers, contrary to the belief prior to this exercis=
e.
> > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of multiple=
 covenant proposals.
> > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not rev=
iewed by enough developers. OP_PARCOMMIT seems to be 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 which is more=
 efficient. Its not the best option for covenants and cannot be used to imp=
rove Ark. Some developers prefer opcodes and not sighash flags.
> >
> > Seems to be the result of an attempt to fix signatures to make them wor=
k for a specific use-case, but the end-result is hard-to-reason (for me) an=
d not flexible. In general, SIGHASH flags are an encoding of specific predi=
cates on the transaction, and I think the Script is better suited to carry =
the predicate. There is no interesting SIGHASH flag that couldn't be functi=
onally simulated by introspection + CHECKSIGFROMSTACK (or other Script-base=
d approaches), and that seems to me a much cleaner and ergonomic way to ach=
ieve 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 sense be=
cause OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same thin=
g. Makes hash caching complex, potentially opening up DoS vectors or quadra=
tic sighash.
> >
> > Most templates you'd obtain with various combinations of parameters are=
 meaningless. It implements state-carrying UTXOs in a very dirty way: addin=
g additional inputs/outputs with no other meaning than "storing some state"=
. This is ugly, inefficient, and bloats the UTXO set - and it definitely wi=
ll happen if TXHASH is enabled without also enabling a clean way to carry s=
tate.
> >
> > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it to=
 what people are actually using covenants for, instead of prematurely optim=
izing 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 cases=
 (DEX, AMM and Hashrate Escrow). Enables granular transaction introspection=
 through abuse of schnorr signatures and OP_CHECKSIG. Can be used for inter=
esting use cases but alone does it poorly and inefficiently.
> >
> > People can and will litter the chain with inefficient/ugly Scripts if a=
ctivated alone. Since it happens to enable generic introspection by acciden=
t, and therefore an ugly version of state-carrying UTXOs, it shouldn't be e=
nabled 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 future=
 and added for specific use case. LN SYMMETRY is possible without this opco=
de. It does not compose with anything that involves transaction introspecti=
on due to its specified tagged hash. Some developers prefer OP_CAT.
> >
> > Not convinced it is impossible that there is no way to simulate CAT wit=
h PAIRCOMMIT, nor confident how much less powerful 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 summary and app=
roving 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 in fa=
vor of OP_CAT and it was rejected.
> > - [Rationale][6] added by Aaron (sCrypt) does not mention anything abou=
t other opcodes and SIGHASH_APO. It is only focused on OP_CAT however evalu=
ations exist in the table.
> > - I [requested][7] Udev (CatSwap) to add details about evaluation of ot=
her opcodes and SIGHASH_APO.
> > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incorrect=
 signet stats and seems to be rephrased version of another rationale. Evalu=
ation had 'weak' for OP_CTV before adding the rationale.
> > - An edit with duplicate rationale (in support of OP_CAT) was rejected =
because sharing the link for a rationale submitted by other developer adds =
no value in the table.
> >
> > Evaluations without a rationale have some 'No' in different cells. Alth=
ough none of them are backed by a rationale so cannot be considered for con=
sensus discussion. The table is still updated regularly so you may see some=
 of them with a rationale in 2025. Any suggestions to help achieve technica=
l 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 evaluations i=
n the table and everyone who shared updates on twitter. It was a coordinate=
d effort to reach some technical consensus. You can read all the rationales=
 in detail to understand different perspectives and reasons to support a co=
mbination of opcodes over others.
> >
> > [1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQA=
J
> > [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/4a14614fa850511d63a5b2a9b5104cb7
> > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?=
permalink_comment_id=3D5359072#gistcomment-5359072
> > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=
=3Dprev&oldid=3D70520
> >
> > /dev/fd0
> > floppy disk guy
> >
> > --
> > 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/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups=
 "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFt=
zC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.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/=
CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.com.