From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 =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,

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

/dev/fd0
floppy disk guy

On Tues= day, December 31, 2024 at 7:53:35=E2=80=AFPM UTC+5:30 moonsettler wrote:
Hi All,

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'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!

=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= . Literally nobody managed to come up with a single use case anyone worth n= oting 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 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's more c= omplex and resource intensive to safely use CAT than PAIRCOMMIT due to witn= ess malleability.

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

This is sufficiently addressed in the BIP.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
OP_VAULT
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> No demand for vaults.

It's safe to completely ignore that "argument".

BR,
moonsettler


On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 <alice...@gmail.com> wrote:

> Hi Bitcoin Developers,
>=20
> 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:
>=20
> - 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.
>=20
> 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].
>=20
> 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.
>=20
> Some insights from the table that could help developers working on= different covenant proposals:
>=20
> 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.
> 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mul= tiple covenant proposals.
> 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are no= t reviewed by enough developers. OP_PARCOMMIT seems to be controversial at = 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 efficient. Its not the best option for covenants and cannot be used t= o improve Ark. Some developers prefer opcodes and not sighash flags.
>=20
> 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'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.
>=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 undesirabl= e use cases. Unaddressed comments in the BIP and the delay doesn'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.
>=20
> Most templates you'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 "stori= ng some state". 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.
>=20
> 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.
>=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 (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.
>=20
> 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.
>=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 anythin= g relevant in the 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 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.
>=20
> 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.
>=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 an= d approving edits. There are a few things that I want to share and it could= be a result of the aggressive marketing:
>=20
> - 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 inco= rrect 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 reje= cted because sharing the link for a rationale submitted by other developer = adds no value in the table.
>=20
> Evaluations without a rationale have some 'No' 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.
>=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 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.
>=20
> [1]: https://groups.google.co= m/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-0= 348.md
> [5]: https://gist.github.com/Ademan/4a= 14614fa850511d63a5b2a9b5104cb7
> [6]: https://gist.github.com/gitzhou= /dc92c41db1987db16fe665c26bc56dd9
> [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permalin= k_comment_id=3D5359072#gistcomment-5359072
> [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_= support&diff=3Dprev&oldid=3D70520
>=20
> /dev/fd0
> floppy disk guy
>=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 email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a900= 7n%40googlegroups.com.

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