path: root/0f/9f03d18058b4c1695a6fb824b2a3e86e75d198

Delivery-date: Wed, 01 Jan 2025 17:24:50 -0800
Received: from mail-yb1-f186.google.com ([209.85.219.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBWGV265QMGQEUKHURHY@googlegroups.com>)
	id 1tT9xB-0003l7-Ab
	for bitcoindev@gnusha.org; Wed, 01 Jan 2025 17:24:50 -0800
Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e5382ab0b41sf379967276.2
        for <bitcoindev@gnusha.org>; Wed, 01 Jan 2025 17:24:48 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1735781083; cv=pass;
        d=google.com; s=arc-20240605;
        b=bCEJEhbZVBo179AHhfB5Yix59sNG4dEkBs/Ezmn7PgdFQdTUa6xjHP/vDn3X1JodHg
         BHD6SdQzSyTXurHnIelPG8uiywXotNjQFeBGeeQzoazyFGTsH2h0rY/nvdWJpYPEXgLm
         /X8Sz9YwNLnUnkiWygEadCTAbJCVxrYNz/S0WEEK8qs5KAQWmqdiSOKijkJyQlNcz8mI
         +asI0Q/+ss5MaGWtC93ttfR5+flxq8jatbHZ9i7ELl9xzQHHAr/lZDYFd9g51HF6SnOf
         sk9EWfGGv75VqbPqrbK9JjzNly6lb1VIj8S0NuYFFgohTLVktRofeaXnSQrs29k8+p5b
         KMXg==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=;
        fh=GMt1VkO63i7KsAeUbhnNJXmrghg1ivjjInDKv0PonxM=;
        b=jVlWshqgJBKvYX1J8vxmsEYeBOQnE+4yAxPQccBPhSL4v//zU8J2TXCZaJVkDYg7ws
         mNW4pmY/aF+1FUfQNOKG0pUSDFMpolbOlk4ILPYCpx5Le6+Az2OL3L0KGd23YBQTEUhD
         O7vtnTnvB1WPVuHKG9vMkxz0/tRK7CjPFC4ppv0r1nJ6q5tXd91zOo3ytxSwmdS4Yll+
         SgVfBykmRJsqosATcM9ltPmrNMJEGdrCOCX/snQP67lOl0JfbuAh02w1RrP4GOJjoqc7
         nAR8DHb79kDpLAnLMyQQQndRh2Hmp2uZyxT26PU1Dyaapg4Dcn1VEDhkYYrgwTn4a90L
         Dpug==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) smtp.mailfrom=alicexbtong@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=1735781083; x=1736385883; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=;
        b=hv6HCH5DtFBMh0oQsF+juivV2v65iLZZUDO8BwiiBMVdPwshgGvYTYxWAv7DZ2R/li
         nY0bpqsEtoequ4g5Zx8uQfN6dGFUpQuET/Ll6quee/ngVnUDD2VR9iP5iVuqbqLrnGW6
         xkKhkXGBfX4ZgjJNkouuPfTVJhcDpLDAoKnQpyvQKOwzYNgoA6bzvPXd7oYtD+A6Y4rm
         oy5gNWYGaN9rj5uiOaLzbJWRumyuHzG5rTyvqB9Cl40TOZvQeuKptIVoIiiKEh7s7owI
         v7OK1ydRoAJhG/wUGBs2/7v02aIdqqiPuBbxmrn0PddbNWTcR1OZ9K08wX+nDI44zauH
         c6Xg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735781083; x=1736385883; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=;
        b=S5/eeR9XBzFcMZhCf8/ZOZOZnh4r+PkkchiTd8lDb88ArFrNq1qD4Gg867FghdmsL6
         lbt//SKhRmRHLSFvfv5iWVB3Tdsn1YFXX70fDcmp0vA5Z/00mbPvK5+G5vNSpOagan3z
         +F08q9npsfS9il8KLpjm+FasGlJ5N0X1brILaB2NjFuUhx4Jh38H97xvd32r0TQQV+7A
         WzKMx5t631JFgS3PDTr5+jnWiTcN47RC+neZvIIi0p2++8HR0BAlRW3eLu4Fzv2XZjd5
         OqU15ONH8ourWZ+WzsmmD32Ql+7mKgLHKLr28aQnrvTx6VAdHlCEPtPkUu3wbTiKUU/D
         EtNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735781083; x=1736385883;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender: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=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=;
        b=Lom26NrHvKLc2CBsQxsblachU2B9CBtiFvC68rtRNC449J61VZuG/Semu8BkG8XLvx
         bIikxYakIWXgJHnJusGTsbLlQLCf2qepSoe3NFYhfceSIyHY1Px2tvG4MDLZiioarenP
         Nm5tdBUiqd/m4MuNLbT4zJ6h3wJMoZYJ9YfIegYh3jzwDZKEocI1Hx21VU+welmpNdUi
         jFUrLF2e70NNybG5UrfE7Kro7CFJhUXtrhjQj9rS928Etw+rXXtrzqCNb+mNMmaL+XHY
         DigWIiCrx/CjcvbBwTAZT+lc21UVsvr7LoXHG+o3xP3ZijWHd8dJdRFNCP9tQSmNp9AI
         IyQw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW/eHklDlhRIyPikZ/0HiXMttjsxS4uZlqr9OEnKoU2yYGkYhxbrgJdWBmipzeCLvzfiyU5qxEMzyxv@gnusha.org
X-Gm-Message-State: AOJu0YygC6WWcLjk/tIdTdrL8MkhrvDk+PwZKDMkeIOKo1fgalwuzrOO
	od6z+QwsQXOcT61yuqBTxbFh+2vje48/37gRBpFZk9uoFfH26yQi
X-Google-Smtp-Source: AGHT+IHlxAl7Vktn0zU41MPioLSRzhnB7SO4IaFA+31fIogJOmf2Wd2hLyT6s0gf+qHMkg23xkL3fQ==
X-Received: by 2002:a05:6902:248e:b0:e4a:8132:26b3 with SMTP id 3f1490d57ef6-e538c40e1a7mr30301846276.47.1735781082653;
        Wed, 01 Jan 2025 17:24:42 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:aa69:0:b0:e48:25c2:a5d7 with SMTP id 3f1490d57ef6-e5411996a94ls2990495276.0.-pod-prod-06-us;
 Wed, 01 Jan 2025 17:24:40 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCUyQdIihQiLgVUYZdZOBsM7TzPYRdmowIDpJnyPNDDJBAcMncPT8bgcIQFWaFuwm+D5IfDbiGLzwgFv@googlegroups.com
X-Received: by 2002:a05:690c:6407:b0:6ef:4e42:64d0 with SMTP id 00721157ae682-6f3f81253d5mr254406717b3.11.1735781079897;
        Wed, 01 Jan 2025 17:24:39 -0800 (PST)
Received: by 2002:a05:690c:951:b0:6ef:b1a3:15f0 with SMTP id 00721157ae682-6f3f552f45fms7b3;
        Wed, 1 Jan 2025 17:23:20 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCWn7TWjaOAGRewKoVAptnwH8BV08eiQb9sp+EcLcVPoh55B6CavNFvPRBq/1RouhXr46mYnEGk+KGVM@googlegroups.com
X-Received: by 2002:a05:6902:2610:b0:e4a:fc25:30cb with SMTP id 3f1490d57ef6-e538c40c90amr30928530276.46.1735780999474;
        Wed, 01 Jan 2025 17:23:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1735780999; cv=none;
        d=google.com; s=arc-20240605;
        b=ZnZT4WpmE1B0R3s4478itwvtrZezZjLkR3moQWdCizXvKp1W4zoG8zp/xyHpX2hPaE
         Eu2Q7x3edF1MOAgVIZfLonAM65hFVqxOJEkUHvnJZ5TUgAjC/wF9yU79SvDWc6bd8eiB
         phnQHxXDjO06iG9Fl0mSipNfENFQKaDY83e8phI0IwAG2BClm1lDSa8uW/hiOY0yVPZa
         IloNuo+O5FKMXQqfkm3G/76fR91iHili+8mnIu91Ev3Dk9N2oxS0BW4kP2ez2zCtAEhE
         xTgYvfFvNwIK2bL/U3ZCsCdfTRLUQHgPJCHOAXHH7gK/xl2KNEhsByyONEZJAsyjM0v9
         vTjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=PQGXIn1YFjxjLYo5+2iuY1cuME9ULKy6D+7DIPghF/s=;
        fh=IEg/iXUBTFPwmhcumGuuPv+LgOJa1X9ae1fKQ33VqzQ=;
        b=WBWRsqlmApcsMDQiLTOVq00Qc0cQqfFVj3UY4qXuAsYUoyEpUvxSAmkvcd711KoJNV
         Wfl4ZadvNwQ3BcBvuPt4de7X1qe2VJSUylhVihgHuok89KS0pONNyWcv9+L7IfF0eh9I
         +zmyUBk0NzxlKl1mZt6xT3gWJf9hsRxMBFZDoDQ+X2cvh2gKLTMogKY752SkhR8i2/k+
         RxXxkR073BYXiU8FSRCQ2AO9xww1kpqGwzKFcuBwWjPU0DScDQffUwHLil7FktJGtZhq
         6oL72ULdQgj1nZwEUluRsRGPXln8FrMs7gHkD2k1cxdrJIKoxljcvv3EfF0mg87VOY1z
         M3gQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com. [2607:f8b0:4864:20::c31])
        by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e537cc20c65si1019341276.1.2025.01.01.17.23.19
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 01 Jan 2025 17:23:19 -0800 (PST)
Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) client-ip=2607:f8b0:4864:20::c31;
Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-5f2d5b3c094so2120894eaf.1
        for <bitcoindev@googlegroups.com>; Wed, 01 Jan 2025 17:23:19 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCVe8TO2x8AmWUlx+F+QExjiRObvyWtWBnFYELgykoqJwuYA9Q0j5gi5cntrwrrUM85TATAJAELi+pxU@googlegroups.com
X-Gm-Gg: ASbGnctO3pT4AesPG0JmKdDg+3ZF1Qz0ue70xVxxKi2BRVCvl5CM+LCGl4gXQFag3w2
	EFclvCCYQLbAwOoH6DUl6r1HA+8JHxLuaJRlcF70D
X-Received: by 2002:a05:6870:3921:b0:297:241b:1471 with SMTP id
 586e51a60fabf-2a7fb4181d6mr24888164fac.41.1735780997374; Wed, 01 Jan 2025
 17:23:17 -0800 (PST)
MIME-Version: 1.0
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
 <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
 <CAEM=y+V9Gu0n7pLv1d+K1HfaFsB3kXg-LbtppyZG0xjAa7DBaA@mail.gmail.com>
In-Reply-To: <CAEM=y+V9Gu0n7pLv1d+K1HfaFsB3kXg-LbtppyZG0xjAa7DBaA@mail.gmail.com>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Thu, 2 Jan 2025 06:52:58 +0530
Message-ID: <CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA@mail.gmail.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
To: Ethan Heilman <eth3rs@gmail.com>
Cc: moonsettler <moonsettler@protonmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000c1ad61062aaf01c5"
X-Original-Sender: alicexbtong@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ;       spf=pass
 (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31
 as permitted sender) smtp.mailfrom=alicexbtong@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 (/)

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

Hi Ethan,

OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas
OP_PAIRCOMMIT is a part of LNHANCE.

In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN
SYMMETRY can be achieved with other opcodes.

Note: The objections shared in this thread are a summarised version of all
the rationales and not my person opinion.

/dev/fd0
floppy disk guy

On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth3rs@gmail.com> wrote:

> One of the CAT authors here
>
> > > [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
> commitments 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 malleability.
>
> 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
> PAIRCOMMIT.
>
> 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 Develop=
ment
> 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 activation client and try to gain consensus on that. There are plent=
y
> of version 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 strongly opposed by many who did not choose to participate. I'm n=
ot
> convinced that this table represents actual developer, let alone ecosyste=
m
> consensus. If you decide you want to run an alternative activation effort
> 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.
> Literally 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 correlation between the age of the proposals and their support with
> the sole exception 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
> commitments 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 malleability.
> >
> > > Not convinced it is impossible that there is no way to simulate CAT
> with 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
> '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 [podcast
> 333][2]. I have started working on a [page][3] that lists use cases,
> prototype links and primitives used. We can still add more use cases in i=
t.
> This list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4]
> alone or in combination with other opcodes like [LN SYMMETRY][5].
> > >
> > > I had verified each entry to avoid spam and fake evaluations. 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.
> > >
> > > Some insights from the table that could help developers working on
> different covenant proposals:
> > >
> > > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO
> lacks interest among developers, contrary to the belief prior to this
> exercise.
> > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of
> multiple covenant proposals.
> > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not
> reviewed 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
> 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 m=
e)
> and not flexible. In general, SIGHASH flags are an encoding of specific
> predicates on the transaction, and I think the Script is better suited to
> carry the predicate. There is no interesting SIGHASH flag that couldn't b=
e
> functionally simulated by introspection + CHECKSIGFROMSTACK (or other
> Script-based approaches), and that seems to me a much cleaner and ergonom=
ic
> 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 sen=
se
> because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same
> thing. Makes hash caching complex, potentially opening up DoS vectors or
> quadratic sighash.
> > >
> > > Most templates you'd obtain with various combinations of parameters
> are meaningless. It implements state-carrying UTXOs in a very dirty way:
> adding additional inputs/outputs with no other meaning than "storing some
> state". This is ugly, inefficient, and bloats the UTXO set - and it
> definitely will happen if TXHASH is enabled without also enabling a clean
> way to carry state.
> > >
> > > 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.
> > >
> > > =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 interesting 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
> accident, 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
> future and added for specific use case. LN SYMMETRY is possible without
> this opcode. It does not compose with anything that involves transaction
> introspection 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
> 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
> 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 in
> 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
> evaluations exist in the table.
> > > - I [requested][7] Udev (CatSwap) to add details about evaluation of
> other 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. Evaluation had 'weak' for OP_CTV before adding the rationale.
> > > - An edit with duplicate rationale (in support of OP_CAT) was rejecte=
d
> because sharing the link for a rationale submitted by other developer add=
s
> 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 f=
or
> 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
> 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 evaluations
> in the table and everyone who shared updates on twitter. It was a
> coordinated effort to reach some technical consensus. You can read all th=
e
> rationales 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/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]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
> > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> > > [7]:
> https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permali=
nk_comment_id=3D5359072#gistcomment-5359072
> > > [8]:
> 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 Google
> Groups "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/bitcoindev/38a6f252-afe9-4155-a341-11a4=
2a9a9007n%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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmc=
uQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frB=
WXac%3D%40protonmail.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/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/=
CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.gmail.com.

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

<div dir=3D"auto">Hi Ethan,<div dir=3D"auto"><br></div><div dir=3D"auto">OP=
_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAIRCOM=
MIT is a part of LNHANCE.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN SYM=
METRY can be achieved with other opcodes.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Note: The objections shared in this thread are a summaris=
ed version of all the rationales and not my person opinion.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">/dev/fd0</div><div dir=3D"auto">flopp=
y disk guy</div></div><br><div class=3D"gmail_quote gmail_quote_container">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 1, 2025, 11:49 PM Ethan H=
eilman &lt;<a href=3D"mailto:eth3rs@gmail.com">eth3rs@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">One of the CAT authors here<br>
<br>
&gt; &gt; [PAIR_COMMIT] Adds unnecessary complexity<br>
&gt; That&#39;s a subjective value judgement it enables something that was =
no possible before which is interacting with Merkle trees and multi-element=
 commitments in script. PAIRCOMMIT is not significantly more complicated th=
an 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 PAIRCOMMIT due to wit=
ness malleability.<br>
<br>
PAIR_COMMIT (BIP-442) for all intents and purposes is as simple in<br>
implementation at CAT (BIP-347). I have no technical objection to<br>
PAIRCOMMIT and it provides much needed functionality.<br>
<br>
My primary concern is not PAIRCOMMIT itself, but the rationale for PAIRCOMM=
IT.<br>
<br>
The rationale for PAIRCOMMIT rests on the assumption that the Bitcoin<br>
community does not want the expressiveness of CAT. If we assume this<br>
is the case, then we should be very careful PAIRCOMMIT does not enable<br>
this expressiveness as well. On the other hand, if the Bitcoin<br>
community does want the expressiveness of CAT, then we should merge<br>
CAT. PAIRCOMMIT is well designed to be less expressive than CAT and it<br>
is likely that you can not simulate CAT with PAIRCOMMIT. That said, I<br>
am not convinced it is impossible that there is no way to simulate CAT<br>
with PAIRCOMMIT, nor I do feel confident that I know how much less<br>
powerful PAIRCOMMIT is than CAT.<br>
<br>
Playing devil&#39;s advocate for a second, if I was opposed to CAT on<br>
grounds that we should limit expressiveness I would want to really<br>
understand the limits of PAIRCOMMIT. For instance can you do arbitrary<br>
computation by building STARKs with PAIRCOMMIT merkle trees? If not,<br>
why not?<br>
<br>
That said, I have not heard any argument against PAIRCOMMIT from those<br>
against CAT, so perhaps they are comfortable with it.<br>
<br>
Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.<br>
<br>
On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM &#39;moonsettler&#39; via Bitcoin D=
evelopment<br>
Mailing List &lt;<a href=3D"mailto:bitcoindev@googlegroups.com" target=3D"_=
blank" rel=3D"noreferrer">bitcoindev@googlegroups.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi All,<br>
&gt;<br>
&gt; 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 p=
art of LNhance and will be part of the activation client we release soon. T=
he only way to change that is to demonstrate actual harm. You liking someth=
ing else more, is your problem. What you can do about it, is write your act=
ivation client and try to gain consensus on that. There are plenty of versi=
on 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 str=
ongly opposed by many who did not choose to participate. I&#39;m not convin=
ced that this table represents actual developer, let alone ecosystem consen=
sus. If you decide you want to run an alternative activation effort with CA=
T instead of PAIRCOMMIT feel free to fork our repo!<br>
&gt;<br>
&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; OP_PARCOMMIT<br>
&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;<br>
&gt; &gt; OP_PARCOMMIT seems to be controversial at this moment.<br>
&gt;<br>
&gt; I strongly disagree. In my book that&#39;s not what controversial mean=
s. 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 young, there is=
 a clear correlation between the age of the proposals and their support wit=
h the sole exception of APO.<br>
&gt;<br>
&gt; &gt; Adds unnecessary complexity<br>
&gt;<br>
&gt; That&#39;s a subjective value judgement it enables something that was =
no possible before which is interacting with Merkle trees and multi-element=
 commitments in script. PAIRCOMMIT is not significantly more complicated th=
an 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 PAIRCOMMIT due to wit=
ness malleability.<br>
&gt;<br>
&gt; &gt; Not convinced it is impossible that there is no way to simulate C=
AT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than=
 CAT.<br>
&gt;<br>
&gt; This is sufficiently addressed in the BIP.<br>
&gt;<br>
&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; OP_VAULT<br>
&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;<br>
&gt; &gt; No demand for vaults.<br>
&gt;<br>
&gt; It&#39;s safe to completely ignore that &quot;argument&quot;.<br>
&gt;<br>
&gt; BR,<br>
&gt; moonsettler<br>
&gt;<br>
&gt;<br>
&gt; On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 &lt;<a href=3D"m=
ailto:alicexbtong@gmail.com" target=3D"_blank" rel=3D"noreferrer">alicexbto=
ng@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi Bitcoin Developers,<br>
&gt; &gt;<br>
&gt; &gt; I had shared covenants support wiki page link here on [mailing li=
st][1] in the last week of November 2024. Multiple changes were made based =
on the feedback:<br>
&gt; &gt;<br>
&gt; &gt; - Removed &#39;community support&#39; from &#39;No&#39;. Rephrase=
d definitions for &#39;Prefer&#39; and &#39;Evaluating&#39;.<br>
&gt; &gt; - Added LNHANCE category for a combination of opcodes.<br>
&gt; &gt; - Added links for BIP drafts and a column for &#39;rationale&#39;=
.<br>
&gt; &gt; - Created a separate table for evaluations without a rationale.<b=
r>
&gt; &gt;<br>
&gt; &gt; Murch and Gloria shared their feedback in the bitcoin optech [pod=
cast 333][2]. I have started working on a [page][3] that lists use cases, p=
rototype links and primitives used. We can still add more use cases in it. =
This list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] a=
lone or in combination with other opcodes like [LN SYMMETRY][5].<br>
&gt; &gt;<br>
&gt; &gt; I had verified each entry to avoid spam and fake evaluations. Rea=
rden was assigned moderator permissions on 8 December 2024 by Theymos to he=
lp me with the moderations. Some edits have been approved by other moderato=
rs.<br>
&gt; &gt;<br>
&gt; &gt; Some insights from the table that could help developers working o=
n different covenant proposals:<br>
&gt; &gt;<br>
&gt; &gt; 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_=
APO lacks interest among developers, contrary to the belief prior to this e=
xercise.<br>
&gt; &gt; 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mu=
ltiple covenant proposals.<br>
&gt; &gt; 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are n=
ot reviewed by enough developers. OP_PARCOMMIT seems to be controversial at=
 this moment.<br>
&gt; &gt;<br>
&gt; &gt; Objections:<br>
&gt; &gt;<br>
&gt; &gt; ```<br>
&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; SIGHASH_APO<br>
&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;<br>
&gt; &gt; LN SYMMETRY is possible with combination of a few opcodes which i=
s more efficient. Its not the best option for covenants and cannot be used =
to improve Ark. Some developers prefer opcodes and not sighash flags.<br>
&gt; &gt;<br>
&gt; &gt; Seems to be the result of an attempt to fix signatures to make th=
em work for a specific use-case, but the end-result is hard-to-reason (for =
me) and not flexible. In general, SIGHASH flags are an encoding of specific=
 predicates on the transaction, and I think the Script is better suited to =
carry the predicate. There is no interesting SIGHASH flag that couldn&#39;t=
 be functionally simulated by introspection + CHECKSIGFROMSTACK (or other S=
cript-based approaches), and that seems to me a much cleaner and ergonomic =
way to achieve the same goals.<br>
&gt; &gt;<br>
&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; OP_TXHASH<br>
&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;<br>
&gt; &gt; More expressive, many flag configurations, untested and undesirab=
le use cases. Unaddressed comments in the BIP and the delay doesn&#39;t mak=
e 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;<br>
&gt; &gt; Most templates you&#39;d obtain with various combinations of para=
meters are meaningless. It implements state-carrying UTXOs in a very dirty =
way: adding additional inputs/outputs with no other meaning than &quot;stor=
ing some state&quot;. This is ugly, inefficient, and bloats the UTXO set - =
and it definitely will happen if TXHASH is enabled without also enabling a =
clean way to carry state.<br>
&gt; &gt;<br>
&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;<br>
&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; OP_VAULT<br>
&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;<br>
&gt; &gt; No demand for vaults. Customized for a specific use case.<br>
&gt; &gt;<br>
&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; OP_CAT<br>
&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;<br>
&gt; &gt; Can be used for various complex scripts including undesirable use=
 cases (DEX, AMM and Hashrate Escrow). Enables granular transaction introsp=
ection through abuse of schnorr signatures and OP_CHECKSIG. Can be used for=
 interesting use cases but alone does it poorly and inefficiently.<br>
&gt; &gt;<br>
&gt; &gt; People can and will litter the chain with inefficient/ugly Script=
s if activated alone. Since it happens to enable generic introspection by a=
ccident, and therefore an ugly version of state-carrying UTXOs, it shouldn&=
#39;t be enabled without more ergonomic opcodes for those use cases.<br>
&gt; &gt;<br>
&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; OP_INTERNALKEY<br>
&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;<br>
&gt; &gt; There are 3 &#39;No&#39; in the table, I couldn&#39;t find anythi=
ng relevant in the rationales.<br>
&gt; &gt;<br>
&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; OP_PAIRCOMMIT<br>
&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;<br>
&gt; &gt; Adds unnecessary complexity, redundant if OP_CAT is activated in =
future and added for specific use case. LN SYMMETRY is possible without thi=
s opcode. It does not compose with anything that involves transaction intro=
spection due to its specified tagged hash. Some developers prefer OP_CAT.<b=
r>
&gt; &gt;<br>
&gt; &gt; Not convinced it is impossible that there is no way to simulate C=
AT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than=
 CAT.<br>
&gt; &gt;<br>
&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; OP_CHECKTEMPLATEVERIFY<br>
&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;<br>
&gt; &gt; Limited in scope and not recursive.<br>
&gt; &gt; ```<br>
&gt; &gt;<br>
&gt; &gt; I have tried my best to remain unbiased in writing this summary a=
nd approving edits. There are a few things that I want to share and it coul=
d be a result of the aggressive marketing:<br>
&gt; &gt;<br>
&gt; &gt; - A spammer had edited the table to remove all evaluations except=
 in favor of OP_CAT and it was rejected.<br>
&gt; &gt; - [Rationale][6] added by Aaron (sCrypt) does not mention anythin=
g about other opcodes and SIGHASH_APO. It is only focused on OP_CAT however=
 evaluations exist in the table.<br>
&gt; &gt; - I [requested][7] Udev (CatSwap) to add details about evaluation=
 of other opcodes and SIGHASH_APO.<br>
&gt; &gt; - Last [edit][8] by Roujiamo (bitdollar) has a rationale with inc=
orrect signet stats and seems to be rephrased version of another rationale.=
 Evaluation had &#39;weak&#39; for OP_CTV before adding the rationale.<br>
&gt; &gt; - An edit with duplicate rationale (in support of OP_CAT) was rej=
ected because sharing the link for a rationale submitted by other developer=
 adds no value in the table.<br>
&gt; &gt;<br>
&gt; &gt; Evaluations without a rationale have some &#39;No&#39; in differe=
nt cells. Although none of them are backed by a rationale so cannot be cons=
idered for consensus discussion. The table is still updated regularly so yo=
u may see some of them with a rationale in 2025. Any suggestions to help ac=
hieve technical consensus are most welcome.<br>
&gt; &gt;<br>
&gt; &gt; What&#39;s next?<br>
&gt; &gt;<br>
&gt; &gt; - More rationales in the table<br>
&gt; &gt; - Discuss objections on mailing list (if any)<br>
&gt; &gt; - Workshops<br>
&gt; &gt; - Add a table for economic nodes and their opinion<br>
&gt; &gt; - Build activation client and discuss parameters<br>
&gt; &gt;<br>
&gt; &gt; Finally, I would thank all the developers who added their evaluat=
ions in the table and everyone who shared updates on twitter. It was a coor=
dinated effort to reach some technical consensus. You can read all the rati=
onales in detail to understand different perspectives and reasons to suppor=
t a combination of opcodes over others.<br>
&gt; &gt;<br>
&gt; &gt; [1]: <a href=3D"https://groups.google.com/g/bitcoindev/c/fdxkE1Al=
4TI/m/CeEuls2IAQAJ" rel=3D"noreferrer noreferrer" target=3D"_blank">https:/=
/groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ</a><br>
&gt; &gt; [2]: <a href=3D"https://bitcoinops.org/en/podcast/2024/12/17/" re=
l=3D"noreferrer noreferrer" target=3D"_blank">https://bitcoinops.org/en/pod=
cast/2024/12/17/</a><br>
&gt; &gt; [3]: <a href=3D"https://en.bitcoin.it/wiki/Covenants_Uses" rel=3D=
"noreferrer noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/Covena=
nts_Uses</a><br>
&gt; &gt; [4]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0=
348.md" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/=
bitcoin/bips/blob/master/bip-0348.md</a><br>
&gt; &gt; [5]: <a href=3D"https://gist.github.com/Ademan/4a14614fa850511d63=
a5b2a9b5104cb7" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gis=
t.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7</a><br>
&gt; &gt; [6]: <a href=3D"https://gist.github.com/gitzhou/dc92c41db1987db16=
fe665c26bc56dd9" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gi=
st.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9</a><br>
&gt; &gt; [7]: <a href=3D"https://gist.github.com/udevswap/b768d20d62549922=
b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5359072" rel=3D=
"noreferrer noreferrer" target=3D"_blank">https://gist.github.com/udevswap/=
b768d20d62549922b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment=
-5359072</a><br>
&gt; &gt; [8]: <a href=3D"https://en.bitcoin.it/w/index.php?title=3DCovenan=
ts_support&amp;diff=3Dprev&amp;oldid=3D70520" rel=3D"noreferrer noreferrer"=
 target=3D"_blank">https://en.bitcoin.it/w/index.php?title=3DCovenants_supp=
ort&amp;diff=3Dprev&amp;oldid=3D70520</a><br>
&gt; &gt;<br>
&gt; &gt; /dev/fd0<br>
&gt; &gt; floppy disk guy<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; You received this message because you are subscribed to the Googl=
e 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=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.c=
om" target=3D"_blank" rel=3D"noreferrer">bitcoindev+unsubscribe@googlegroup=
s.com</a>.<br>
&gt; &gt; To view this discussion visit <a href=3D"https://groups.google.co=
m/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.c=
om" rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.c=
om/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.=
com</a>.<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank" rel=3D"noreferrer">bitcoindev+unsubscribe@googlegroups.com=
</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_=
q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.com/d/ms=
gid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q=
3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com</a>.<br=
>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer">bitcoindev+unsubscribe@googlegroups.com</a>.=
<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail=
.gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.=
google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-Lbtppy=
ZG0xjAa7DBaA%40mail.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/CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.g=
mail.com</a>.<br />

--000000000000c1ad61062aaf01c5--