path: root/d7/fa81a091df7b43abccceb2f484ef2e9985e894

Delivery-date: Tue, 31 Dec 2024 17:49:19 -0800
Received: from mail-yb1-f185.google.com ([209.85.219.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBEN62K5QMGQEHU2CAUQ@googlegroups.com>)
	id 1tSnrJ-0002RS-Q9
	for bitcoindev@gnusha.org; Tue, 31 Dec 2024 17:49:19 -0800
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e3886f4cee2sf21047555276.0
        for <bitcoindev@gnusha.org>; Tue, 31 Dec 2024 17:49:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1735696151; x=1736300951; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=/6IshtVBXDXA5sHT2mJmKhg8FFpaf03nZlr849NaHlY=;
        b=Bk3J9xvFcjrUZe8aUZ0XfXk6DN8+1N6Kek7e1ZGHGnJId0MkQCSmMho179fW6AfMyF
         ViA+QgeJh5SjpSjqm+Oqhsy564AxT0RvqVeo8daUK16PJWHbTioBB3P7/HzTKrCPO7AV
         oaCTZFjCbp/bI8xzzA/tinarpwiAgmmDgEGLtf6TYgLbT9m3IXixDUWJkQ1cUv1EHwig
         CZOZ/mAM9QhzlUxNvqZckRFTOFKBfJStw55Xdib7chy6rbNCdbt/T93ruaPqFM47uHqZ
         iUHBQjFGZtafl7XMAjmK068UcB850hxvfUISFxCivxGO6TXptskg5bzlN5YzCTJub39R
         DQDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735696151; x=1736300951; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/6IshtVBXDXA5sHT2mJmKhg8FFpaf03nZlr849NaHlY=;
        b=cIRj4bdkohna3a2GTl6xkHFaVYrv4BpmXt1mThV+xwDaom5NBB7ym+RAaYlgqaDuxv
         Dmjnz38m7nvI9qz/OoMpt760HU1s+nGvBhixkXoAqtfonx1rDXHx6EGhwMRFVGHKESzq
         lF968FiWzpbkR7YjUtfdQQN/Z/3fi34ghAvFV+HYorW4EfNPArkLN3NtT1cDRdhsr6xm
         3wIeqv+Kh18/cEBDdSR4xdijuwzsxdWp2w0/NJ1NTx+QcjxAHjmgiG5RoRlqZ+LQT4H/
         VGkAPKjeVoAr0H0v5BKD1xt8Vzw5qHJBVy379ct39CKKsfQKOcLunxY9jRK6DTej4Vny
         51fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735696151; x=1736300951;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/6IshtVBXDXA5sHT2mJmKhg8FFpaf03nZlr849NaHlY=;
        b=QLPhHGdtNXB0HjCoIC2dS2pi0mpInf1yuJ2QV7t9DHYkQoYum0dMMg8eFaG1sxnuJC
         1PAefQrmaVrKm+IkJw3iFCNB2Nkbu/Cv2XaGFPIuhIASO5lelpb7zxAKuGhgrA7NdQax
         SiqIMEMsPF54ajzZJhzt6YljOxKpoVK5CtXRzKfYic6jJiDJ0fGmjCY0UxngJsCzjEDo
         2PAsPYW7Fetexs5eArFteg15BU9iWIW4VLAbJ9SUFSDqdUyG87sjXdvgkPYSGGK9frWc
         WDPSiKooX4oo6IbADSo4tBdXaYN2jQFshd5b4qKkLexE4rYNsTb+ONe4ellEQOX9anje
         OMNw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXILYmJYCs39ykjfnIzbOw3whdUiVebTKuCUK/ZjSf0nOL8lE2FmJyBywwRg4E3pvVJ42xPNQ9sDCLv@gnusha.org
X-Gm-Message-State: AOJu0YyCNxqJv2U8xGhn1alZ6N7SSwSDQelj5xu/EgcbaKhKrR2gQk1o
	W8rDnf2MV+lye0EXj8eSTIMOEDIS2IBkyw57WF5EzIzJAyWHk0Zd
X-Google-Smtp-Source: AGHT+IFl3iIYTHAXzGll5Ub+vPfRWlm9GyLmEaXTR6URf+sKy9YOyOdDou6reYkXfybGNIIt5Oz3kw==
X-Received: by 2002:a05:6902:2602:b0:e38:230d:aee0 with SMTP id 3f1490d57ef6-e538d0b3662mr35390028276.23.1735696150685;
        Tue, 31 Dec 2024 17:49:10 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:a4a2:0:b0:e39:6d8a:558 with SMTP id 3f1490d57ef6-e537602d28dls312944276.1.-pod-prod-01-us;
 Tue, 31 Dec 2024 17:49:05 -0800 (PST)
X-Received: by 2002:a05:690c:2502:b0:6ef:7d51:ebb3 with SMTP id 00721157ae682-6f3f8223775mr335134227b3.34.1735696145628;
        Tue, 31 Dec 2024 17:49:05 -0800 (PST)
Received: by 2002:a05:690c:b10:b0:6ef:9b37:85ef with SMTP id 00721157ae682-6f484ea9c59ms7b3;
        Tue, 31 Dec 2024 17:46:48 -0800 (PST)
X-Received: by 2002:a05:690c:6a12:b0:6ef:792a:6dfd with SMTP id 00721157ae682-6f3f8251781mr300843907b3.38.1735696007302;
        Tue, 31 Dec 2024 17:46:47 -0800 (PST)
Date: Tue, 31 Dec 2024 17:46:47 -0800 (PST)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <aa731d1c-cadb-4424-839f-f13b4f8bf079n@googlegroups.com>
In-Reply-To: <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
 <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1353832_1450662130.1735696007073"
X-Original-Sender: alicexbtong@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_1353832_1450662130.1735696007073
Content-Type: multipart/alternative; 
	boundary="----=_Part_1353833_530955235.1735696007073"

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

Hi monnsettler,

I have never mentioned this as voting in any of my posts. You are free to=
=20
build activation clients that nobody will run.=20

/dev/fd0
floppy disk guy

On Tuesday, December 31, 2024 at 7:53:35=E2=80=AFPM UTC+5:30 moonsettler wr=
ote:

> Hi All,
>
> One thing I would like to make clear before people get the wrong idea and=
=20
> think this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is par=
t=20
> of LNhance and will be part of the activation client we release soon. The=
=20
> only way to change that is to demonstrate actual harm. You liking somethi=
ng=20
> else more, is your problem. What you can do about it, is write your=20
> activation client and try to gain consensus on that. There are plenty of=
=20
> version bits available. Replacing PAIRCOMMIT with CAT would be really eas=
y,=20
> but while CAT is indeed very popular and has a wide support base it is al=
so=20
> strongly opposed by many who did not choose to participate. I'm not=20
> convinced that this table represents actual developer, let alone ecosyste=
m=20
> consensus. If you decide you want to run an alternative activation effort=
=20
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> OP_PARCOMMIT=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > OP_PARCOMMIT seems to be controversial at this moment.
>
> I strongly disagree. In my book that's not what controversial means.=20
> Literally nobody managed to come up with a single use case anyone worth=
=20
> noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from=
=20
> those that prefer CAT as plain trolling. This BIP is young, there is a=20
> clear correlation between the age of the proposals and their support with=
=20
> the sole exception of APO.
>
> > Adds unnecessary complexity
>
> That's a subjective value judgement it enables something that was no=20
> possible before which is interacting with Merkle trees and multi-element=
=20
> commitments in script. PAIRCOMMIT is not significantly more complicated=
=20
> than CAT, and in a lot of actual use cases CAT was desired for it's more=
=20
> complex and resource intensive to safely use CAT than PAIRCOMMIT due to=
=20
> witness malleability.
>
> > Not convinced it is impossible that there is no way to simulate CAT wit=
h=20
> 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 <alice...@gmail.com=
>=20
> wrote:
>
> > Hi Bitcoin Developers,
> >=20
> > I had shared covenants support wiki page link here on [mailing list][1]=
=20
> in the last week of November 2024. Multiple changes were made based on th=
e=20
> feedback:
> >=20
> > - Removed 'community support' from 'No'. Rephrased definitions for=20
> 'Prefer' and 'Evaluating'.
> > - Added LNHANCE category for a combination of opcodes.
> > - Added links for BIP drafts and a column for 'rationale'.
> > - Created a separate table for evaluations without a rationale.
> >=20
> > Murch and Gloria shared their feedback in the bitcoin optech [podcast=
=20
> 333][2]. I have started working on a [page][3] that lists use cases,=20
> prototype links and primitives used. We can still add more use cases in i=
t.=20
> This list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4]=
=20
> alone or in combination with other opcodes like [LN SYMMETRY][5].
> >=20
> > I had verified each entry to avoid spam and fake evaluations. Rearden=
=20
> was assigned moderator permissions on 8 December 2024 by Theymos to help =
me=20
> with the moderations. Some edits have been approved by other moderators.
> >=20
> > Some insights from the table that could help developers working on=20
> different covenant proposals:
> >=20
> > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO=20
> lacks interest among developers, contrary to the belief prior to this=20
> exercise.
> > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of multiple=
=20
> covenant proposals.
> > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not=20
> reviewed by enough developers. OP_PARCOMMIT seems to be controversial at=
=20
> this moment.
> >=20
> > Objections:
> >=20
> > ```
> > =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
> >=20
> > LN SYMMETRY is possible with combination of a few opcodes which is more=
=20
> efficient. Its not the best option for covenants and cannot be used to=20
> improve Ark. Some developers prefer opcodes and not sighash flags.
> >=20
> > Seems to be the result of an attempt to fix signatures to make them wor=
k=20
> for a specific use-case, but the end-result is hard-to-reason (for me) an=
d=20
> not flexible. In general, SIGHASH flags are an encoding of specific=20
> predicates on the transaction, and I think the Script is better suited to=
=20
> carry the predicate. There is no interesting SIGHASH flag that couldn't b=
e=20
> functionally simulated by introspection + CHECKSIGFROMSTACK (or other=20
> Script-based approaches), and that seems to me a much cleaner and ergonom=
ic=20
> way to achieve the same goals.
> >=20
> > =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
> >=20
> > More expressive, many flag configurations, untested and undesirable use=
=20
> cases. Unaddressed comments in the BIP and the delay doesn't make sense=
=20
> because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same=
=20
> thing. Makes hash caching complex, potentially opening up DoS vectors or=
=20
> quadratic sighash.
> >=20
> > Most templates you'd obtain with various combinations of parameters are=
=20
> meaningless. It implements state-carrying UTXOs in a very dirty way: addi=
ng=20
> additional inputs/outputs with no other meaning than "storing some state"=
.=20
> This is ugly, inefficient, and bloats the UTXO set - and it definitely wi=
ll=20
> happen if TXHASH is enabled without also enabling a clean way to carry=20
> state.
> >=20
> > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it to=
=20
> what people are actually using covenants for, instead of prematurely=20
> optimizing everything with no data.
> >=20
> > =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
> >=20
> > No demand for vaults. Customized for a specific use case.
> >=20
> > =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
> >=20
> > Can be used for various complex scripts including undesirable use cases=
=20
> (DEX, AMM and Hashrate Escrow). Enables granular transaction introspectio=
n=20
> through abuse of schnorr signatures and OP_CHECKSIG. Can be used for=20
> interesting use cases but alone does it poorly and inefficiently.
> >=20
> > People can and will litter the chain with inefficient/ugly Scripts if=
=20
> activated alone. Since it happens to enable generic introspection by=20
> accident, and therefore an ugly version of state-carrying UTXOs, it=20
> shouldn't be enabled without more ergonomic opcodes for those use cases.
> >=20
> > =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
> >=20
> > There are 3 'No' in the table, I couldn't find anything relevant in the=
=20
> rationales.
> >=20
> > =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
> >=20
> > Adds unnecessary complexity, redundant if OP_CAT is activated in future=
=20
> and added for specific use case. LN SYMMETRY is possible without this=20
> opcode. It does not compose with anything that involves transaction=20
> introspection due to its specified tagged hash. Some developers prefer=20
> OP_CAT.
> >=20
> > Not convinced it is impossible that there is no way to simulate CAT wit=
h=20
> PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than CAT.
> >=20
> > =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
> >=20
> > Limited in scope and not recursive.
> > ```
> >=20
> > I have tried my best to remain unbiased in writing this summary and=20
> approving edits. There are a few things that I want to share and it could=
=20
> be a result of the aggressive marketing:
> >=20
> > - A spammer had edited the table to remove all evaluations except in=20
> favor of OP_CAT and it was rejected.
> > - [Rationale][6] added by Aaron (sCrypt) does not mention anything abou=
t=20
> other opcodes and SIGHASH_APO. It is only focused on OP_CAT however=20
> evaluations exist in the table.
> > - I [requested][7] Udev (CatSwap) to add details about evaluation of=20
> other opcodes and SIGHASH_APO.
> > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incorrect=
=20
> signet stats and seems to be rephrased version of another rationale.=20
> Evaluation had 'weak' for OP_CTV before adding the rationale.
> > - An edit with duplicate rationale (in support of OP_CAT) was rejected=
=20
> because sharing the link for a rationale submitted by other developer add=
s=20
> no value in the table.
> >=20
> > Evaluations without a rationale have some 'No' in different cells.=20
> Although none of them are backed by a rationale so cannot be considered f=
or=20
> consensus discussion. The table is still updated regularly so you may see=
=20
> some of them with a rationale in 2025. Any suggestions to help achieve=20
> technical consensus are most welcome.
> >=20
> > What's next?
> >=20
> > - 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
> >=20
> > Finally, I would thank all the developers who added their evaluations i=
n=20
> the table and everyone who shared updates on twitter. It was a coordinate=
d=20
> effort to reach some technical consensus. You can read all the rationales=
=20
> in detail to understand different perspectives and reasons to support a=
=20
> combination of opcodes over others.
> >=20
> > [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]:=20
> https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permali=
nk_comment_id=3D5359072#gistcomment-5359072
> > [8]:=20
> https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=3Dprev&o=
ldid=3D70520
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a4=
2a9a9007n%40googlegroups.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
aa731d1c-cadb-4424-839f-f13b4f8bf079n%40googlegroups.com.

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

Hi monnsettler,<div><br /></div><div>I have never mentioned this as voting =
in any of my posts. You are free to build activation clients that nobody wi=
ll run.=C2=A0<br /><br />/dev/fd0</div><div>floppy disk guy<br /><br /></di=
v><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tues=
day, December 31, 2024 at 7:53:35=E2=80=AFPM UTC+5:30 moonsettler wrote:<br=
/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi All,
<br>
<br>One thing I would like to make clear before people get the wrong idea a=
nd think this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is pa=
rt of LNhance and will be part of the activation client we release soon. Th=
e only way to change that is to demonstrate actual harm. You liking somethi=
ng else more, is your problem. What you can do about it, is write your acti=
vation client and try to gain consensus on that. There are plenty of versio=
n bits available. Replacing PAIRCOMMIT with CAT would be really easy, but w=
hile CAT is indeed very popular and has a wide support base it is also stro=
ngly opposed by many who did not choose to participate. I&#39;m not convinc=
ed that this table represents actual developer, let alone ecosystem consens=
us. If you decide you want to run an alternative activation effort with CAT=
 instead of PAIRCOMMIT feel free to fork our repo!
<br>
<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>OP_PARCOMMIT=20
<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>
<br>&gt; OP_PARCOMMIT seems to be controversial at this moment.
<br>
<br>I strongly disagree. In my book that&#39;s not what controversial means=
. Literally nobody managed to come up with a single use case anyone worth n=
oting 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 with=
 the sole exception of APO.
<br>
<br>&gt; Adds unnecessary complexity
<br>
<br>That&#39;s a subjective value judgement it enables something that was n=
o possible before which is interacting with Merkle trees and multi-element =
commitments in script. PAIRCOMMIT is not significantly more complicated tha=
n CAT, and in a lot of actual use cases CAT was desired for it&#39;s more c=
omplex and resource intensive to safely use CAT than PAIRCOMMIT due to witn=
ess malleability.
<br>
<br>&gt; Not convinced it is impossible that there is no way to simulate CA=
T with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than =
CAT.
<br>
<br>This is sufficiently addressed in the BIP.
<br>
<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>OP_VAULT
<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<br>
<br>&gt; No demand for vaults.
<br>
<br>It&#39;s safe to completely ignore that &quot;argument&quot;.
<br>
<br>BR,
<br>moonsettler
<br>
<br>
<br>On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 &lt;<a href data-=
email-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Hi Bitcoin Developers,
<br>&gt;=20
<br>&gt; I had shared covenants support wiki page link here on [mailing lis=
t][1] in the last week of November 2024. Multiple changes were made based o=
n the feedback:
<br>&gt;=20
<br>&gt; - Removed &#39;community support&#39; from &#39;No&#39;. Rephrased=
 definitions for &#39;Prefer&#39; and &#39;Evaluating&#39;.
<br>&gt; - Added LNHANCE category for a combination of opcodes.
<br>&gt; - Added links for BIP drafts and a column for &#39;rationale&#39;.
<br>&gt; - Created a separate table for evaluations without a rationale.
<br>&gt;=20
<br>&gt; Murch and Gloria shared their feedback in the bitcoin optech [podc=
ast 333][2]. I have started working on a [page][3] that lists use cases, pr=
ototype links and primitives used. We can still add more use cases in it. T=
his list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] al=
one or in combination with other opcodes like [LN SYMMETRY][5].
<br>&gt;=20
<br>&gt; I had verified each entry to avoid spam and fake evaluations. Rear=
den was assigned moderator permissions on 8 December 2024 by Theymos to hel=
p me with the moderations. Some edits have been approved by other moderator=
s.
<br>&gt;=20
<br>&gt; Some insights from the table that could help developers working on=
 different covenant proposals:
<br>&gt;=20
<br>&gt; 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_A=
PO lacks interest among developers, contrary to the belief prior to this ex=
ercise.
<br>&gt; 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mul=
tiple covenant proposals.
<br>&gt; 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are no=
t reviewed by enough developers. OP_PARCOMMIT seems to be controversial at =
this moment.
<br>&gt;=20
<br>&gt; Objections:
<br>&gt;=20
<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; SIGHASH_APO
<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;=20
<br>&gt; 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 t=
o improve Ark. Some developers prefer opcodes and not sighash flags.
<br>&gt;=20
<br>&gt; Seems to be the result of an attempt to fix signatures to make the=
m 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 c=
arry the predicate. There is no interesting SIGHASH flag that couldn&#39;t =
be functionally simulated by introspection + CHECKSIGFROMSTACK (or other Sc=
ript-based approaches), and that seems to me a much cleaner and ergonomic w=
ay to achieve the same goals.
<br>&gt;=20
<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_TXHASH
<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;=20
<br>&gt; More expressive, many flag configurations, untested and undesirabl=
e use cases. Unaddressed comments in the BIP and the delay doesn&#39;t make=
 sense because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the =
same thing. Makes hash caching complex, potentially opening up DoS vectors =
or quadratic sighash.
<br>&gt;=20
<br>&gt; Most templates you&#39;d obtain with various combinations of param=
eters are meaningless. It implements state-carrying UTXOs in a very dirty w=
ay: adding additional inputs/outputs with no other meaning than &quot;stori=
ng some state&quot;. This is ugly, inefficient, and bloats the UTXO set - a=
nd it definitely will happen if TXHASH is enabled without also enabling a c=
lean way to carry state.
<br>&gt;=20
<br>&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;=20
<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;=20
<br>&gt; No demand for vaults. Customized for a specific use case.
<br>&gt;=20
<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_CAT
<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;=20
<br>&gt; Can be used for various complex scripts including undesirable use =
cases (DEX, AMM and Hashrate Escrow). Enables granular transaction introspe=
ction through abuse of schnorr signatures and OP_CHECKSIG. Can be used for =
interesting use cases but alone does it poorly and inefficiently.
<br>&gt;=20
<br>&gt; People can and will litter the chain with inefficient/ugly Scripts=
 if activated alone. Since it happens to enable generic introspection by ac=
cident, 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;=20
<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_INTERNALKEY
<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;=20
<br>&gt; There are 3 &#39;No&#39; in the table, I couldn&#39;t find anythin=
g relevant in the rationales.
<br>&gt;=20
<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_PAIRCOMMIT
<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;=20
<br>&gt; Adds unnecessary complexity, redundant if OP_CAT is activated in f=
uture and added for specific use case. LN SYMMETRY is possible without this=
 opcode. It does not compose with anything that involves transaction intros=
pection due to its specified tagged hash. Some developers prefer OP_CAT.
<br>&gt;=20
<br>&gt; Not convinced it is impossible that there is no way to simulate CA=
T with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than =
CAT.
<br>&gt;=20
<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_CHECKTEMPLATEVERIFY
<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;=20
<br>&gt; Limited in scope and not recursive.
<br>&gt; ```
<br>&gt;=20
<br>&gt; I have tried my best to remain unbiased in writing this summary an=
d approving edits. There are a few things that I want to share and it could=
 be a result of the aggressive marketing:
<br>&gt;=20
<br>&gt; - A spammer had edited the table to remove all evaluations except =
in favor of OP_CAT and it was rejected.
<br>&gt; - [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.
<br>&gt; - I [requested][7] Udev (CatSwap) to add details about evaluation =
of other opcodes and SIGHASH_APO.
<br>&gt; - Last [edit][8] by Roujiamo (bitdollar) has a rationale with inco=
rrect 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; - An edit with duplicate rationale (in support of OP_CAT) was reje=
cted because sharing the link for a rationale submitted by other developer =
adds no value in the table.
<br>&gt;=20
<br>&gt; Evaluations without a rationale have some &#39;No&#39; in differen=
t cells. Although none of them are backed by a rationale so cannot be consi=
dered 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 ach=
ieve technical consensus are most welcome.
<br>&gt;=20
<br>&gt; What&#39;s next?
<br>&gt;=20
<br>&gt; - More rationales in the table
<br>&gt; - Discuss objections on mailing list (if any)
<br>&gt; - Workshops
<br>&gt; - Add a table for economic nodes and their opinion
<br>&gt; - Build activation client and discuss parameters
<br>&gt;=20
<br>&gt; Finally, I would thank all the developers who added their evaluati=
ons in the table and everyone who shared updates on twitter. It was a coord=
inated effort to reach some technical consensus. You can read all the ratio=
nales in detail to understand different perspectives and reasons to support=
 a combination of opcodes over others.
<br>&gt;=20
<br>&gt; [1]: <a href=3D"https://groups.google.com/g/bitcoindev/c/fdxkE1Al4=
TI/m/CeEuls2IAQAJ" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/g/=
bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ&amp;source=3Dgmail&amp;ust=3D173578=
2056479000&amp;usg=3DAOvVaw2h2Ok4FNis0IvKZln8vM3c">https://groups.google.co=
m/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ</a>
<br>&gt; [2]: <a href=3D"https://bitcoinops.org/en/podcast/2024/12/17/" tar=
get=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.=
com/url?hl=3Den&amp;q=3Dhttps://bitcoinops.org/en/podcast/2024/12/17/&amp;s=
ource=3Dgmail&amp;ust=3D1735782056479000&amp;usg=3DAOvVaw2LZjKe53OcXeKXXuKW=
KGyY">https://bitcoinops.org/en/podcast/2024/12/17/</a>
<br>&gt; [3]: <a href=3D"https://en.bitcoin.it/wiki/Covenants_Uses" target=
=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com=
/url?hl=3Den&amp;q=3Dhttps://en.bitcoin.it/wiki/Covenants_Uses&amp;source=
=3Dgmail&amp;ust=3D1735782056479000&amp;usg=3DAOvVaw3lfOO5nO5_7dScVTQcMh2K"=
>https://en.bitcoin.it/wiki/Covenants_Uses</a>
<br>&gt; [4]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-03=
48.md" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bips/blob/mast=
er/bip-0348.md&amp;source=3Dgmail&amp;ust=3D1735782056479000&amp;usg=3DAOvV=
aw219JgHPOl-q__-GKXHBJae">https://github.com/bitcoin/bips/blob/master/bip-0=
348.md</a>
<br>&gt; [5]: <a href=3D"https://gist.github.com/Ademan/4a14614fa850511d63a=
5b2a9b5104cb7" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.github.com/Ademan/4a=
14614fa850511d63a5b2a9b5104cb7&amp;source=3Dgmail&amp;ust=3D173578205647900=
0&amp;usg=3DAOvVaw3zJC1LhYI11Iv6h2qhHrNJ">https://gist.github.com/Ademan/4a=
14614fa850511d63a5b2a9b5104cb7</a>
<br>&gt; [6]: <a href=3D"https://gist.github.com/gitzhou/dc92c41db1987db16f=
e665c26bc56dd9" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"=
https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.github.com/gitzhou/=
dc92c41db1987db16fe665c26bc56dd9&amp;source=3Dgmail&amp;ust=3D1735782056479=
000&amp;usg=3DAOvVaw1gXk3CbGQiVzEHqGuYQDTM">https://gist.github.com/gitzhou=
/dc92c41db1987db16fe665c26bc56dd9</a>
<br>&gt; [7]: <a href=3D"https://gist.github.com/udevswap/b768d20d62549922b=
9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5359072" target=
=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com=
/url?hl=3Den&amp;q=3Dhttps://gist.github.com/udevswap/b768d20d62549922b9e72=
428ef9eb608?permalink_comment_id%3D5359072%23gistcomment-5359072&amp;source=
=3Dgmail&amp;ust=3D1735782056479000&amp;usg=3DAOvVaw33r66irSw7pstJyf6K5ACL"=
>https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permalin=
k_comment_id=3D5359072#gistcomment-5359072</a>
<br>&gt; [8]: <a href=3D"https://en.bitcoin.it/w/index.php?title=3DCovenant=
s_support&amp;diff=3Dprev&amp;oldid=3D70520" target=3D"_blank" rel=3D"nofol=
low" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhtt=
ps://en.bitcoin.it/w/index.php?title%3DCovenants_support%26diff%3Dprev%26ol=
did%3D70520&amp;source=3Dgmail&amp;ust=3D1735782056479000&amp;usg=3DAOvVaw3=
19vj6w7rsiq3FX9jnLsTL">https://en.bitcoin.it/w/index.php?title=3DCovenants_=
support&amp;diff=3Dprev&amp;oldid=3D70520</a>
<br>&gt;=20
<br>&gt; /dev/fd0
<br>&gt; floppy disk guy
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
38a6f252-afe9-4155-a341-11a42a9a9007n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1735782056479000&amp;usg=3DAOvVaw2ZtZooH-nTNUFUza1fc5BW">https=
://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a900=
7n%40googlegroups.com</a>.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aa731d1c-cadb-4424-839f-f13b4f8bf079n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/aa731d1c-cadb-4424-839f-f13b4f8bf079n%40googlegroups.com</a>.<br />

------=_Part_1353833_530955235.1735696007073--

------=_Part_1353832_1450662130.1735696007073--