From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Jan 2025 12:09:17 -0800 Received: from mail-yb1-f191.google.com ([209.85.219.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tY9hT-0001aI-9e for bitcoindev@gnusha.org; Wed, 15 Jan 2025 12:09:17 -0800 Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e572df6db3esf394267276.3 for ; Wed, 15 Jan 2025 12:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1736971749; x=1737576549; 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=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=; b=gUX5fEJWVVnMkEQHZkwoHLSuS79IGBWRlB4GlgyeFQTfleHL90+KNk4/4jZV/IYRdP JBY7FBkTO48Wh89UGfA+BmqNxE71Z0XgyEWXuJNL9g5LJQWOIR8fQOy0MKD/VTuscyNc msq2hUL3btofMjlbJH1UlRhxc/QIWXzsJdGH59mKJNLyvS5A8GwwUqvYyiGwUKBNrbA8 lkxtWEWIhgFIVuUeFeaGjEbSTHHsb7Q2QRkdZH2kzK4YBBE/SXtP76KdumMqIr0jMTpD fbS0mBQ5JK4zw/K4Iipdt9Dszrt9NI8vh508e+MHRLEeaCwV8tkGGBe87gxAMyNGXzT3 GyUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736971749; x=1737576549; 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=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=; b=QN/kvMBgmzWgqmXrMYoZ2EOXnYCmRwJaZX9Fm+D5II1gCM3m0cATIh5C9anamo7GWY +n7DS3hl59Yy58bCD/XLRMNKRmnTxwj4KWOUGppg9HXcejKk1Hc+2YSfw1ayS5GUvuW/ 1hmYO9H88mS6vgDKdMwkZFpeJVSjTfZrbbEadPmAhIx5UpTal2cDKFUH043CosUqhdLK Qg/nSCRu8M8nhDzKEtTyUcDkAdbUdNZdgPY6QrLsIWT8ajntBLfzEgoLUcdkBQR9W4sL 8VFfzunLqPy4Ewj/jroqPlElIZ0bqpBaum0dAO+nqdhNKal9yBWwRlA0QdBHdEVfs6KN FDzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736971749; x=1737576549; 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=PgOJh/MTTAOc5N5ogV2EPXo06NTPPQePAHwBVuLcQ94=; b=KRU9SGGHMEcBYFypXlB5Ia6pnyB87aOEzdDdEFZ9mnq1dDxQHTys2Wv6M7HPlN07Uw gh+aOzWWtNd7h+Xyf/o/V4RS91JcmR6bpRo/Y2+mpu43ua+aKAxwY6r0B5N/NMOjQNvL 31M+FpbCPtEQ+0nIumRwqdu0ubmq8ylc2nGglhitCq/ylrsXE7R4t0tNXCV3VimDxXeO o5H4i2ksV83j8Y3CtlN2yDDfN0tmZgtwRs1Id25Pj5YpK+081w08XJDvCIaCSrsp30Ue WEU74TIK2d6TZBZpGHVh/JWi0I8OWQwe798OoerIWQphJLLCkVeP0HBaWyxFhomLZw9Z JfGA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXG4n2IH75kewNDHMwfXZrZRdxAWzSc+ipjY0Ad764e9xtFaWLQ4P9cG4Tfcf4N6jCX46pzUXba9J+w@gnusha.org X-Gm-Message-State: AOJu0YwvK+QE2DhCEuEsZ4X2VseAVU5P+Hp/+4QqwWwyqY2CWNj7JO52 jcr0uQoMvPGnXXthB2yEMvUeTspTYR7kdGhInnLI7ZxjSNc4pa6K X-Google-Smtp-Source: AGHT+IHQDpq5KZKwOZMioQN0cw+hSrNLhcAUtKjfS5bcS5BkJ7mT+FfkEgm5xBKDgXBx0KvTqYF9WQ== X-Received: by 2002:a25:8c1:0:b0:e3a:1735:b24e with SMTP id 3f1490d57ef6-e54edf25fb1mr19221866276.2.1736971748534; Wed, 15 Jan 2025 12:09:08 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:6ed6:0:b0:e57:32d7:dded with SMTP id 3f1490d57ef6-e579cb5e882ls217819276.1.-pod-prod-05-us; Wed, 15 Jan 2025 12:09:06 -0800 (PST) X-Received: by 2002:a05:690c:9c03:b0:6ef:641a:2a90 with SMTP id 00721157ae682-6f5312be4bcmr245273107b3.32.1736971745871; Wed, 15 Jan 2025 12:09:05 -0800 (PST) Received: by 2002:a05:690c:9a86:b0:6ef:7d10:5a2f with SMTP id 00721157ae682-6f5d2c70edcms7b3; Tue, 14 Jan 2025 06:14:39 -0800 (PST) X-Received: by 2002:a05:690c:6ac9:b0:6ef:8c41:def8 with SMTP id 00721157ae682-6f53132900amr191465867b3.38.1736864078275; Tue, 14 Jan 2025 06:14:38 -0800 (PST) Date: Tue, 14 Jan 2025 06:14:37 -0800 (PST) From: /dev /fd0 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com> References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com> Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_534798_751735772.1736864077681" 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_534798_751735772.1736864077681 Content-Type: multipart/alternative; boundary="----=_Part_534799_1161673789.1736864077681" ------=_Part_534799_1161673789.1736864077681 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have been discussing the objections shared by Jonas Nick in his=20 rationale:=20 https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4b5a51 Feel free to comment if you'd like to add something. /dev/fd0 floppy disk guy On Friday, January 3, 2025 at 5:45:29=E2=80=AFPM UTC+5:30 moonsettler wrote= : > Hi FLoppy, > > Of course I appreciate thoughtful evaluations. > > But my point stands, I encourage everyone to look at this table as means= =20 > to engage in discussion not some indicator of "consensus" by any means. > > And I emphasized this, because there was a weird perception emerging, and= =20 > even your own summary had this feel to it. > > BR, > moonsettler > > > Sent with Proton Mail secure email. > > On Thursday, January 2nd, 2025 at 4:16 PM, /dev /fd0 = =20 > wrote: > > > Hi moonsettler, > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does.= =20 > They make it more efficient, and they also help other contracts. > > Among them: Resumeable LN channels, Multi-party LN channels, Vaults, et= c. > >=20 > > I am aware of this and have used the comparison table in my=20 > [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY= . > >=20 > > > Calling it "unnecessary complexity" is not a valid technical=20 > observation in any shape or form. It would provide optimization for many= =20 > contracts and use cases even if we had CAT. I explained this to you in=20 > private first, yet you keep insisting on this completely invalid objectio= n. > >=20 > > It is a valid objection and I find it disappointing that you think=20 > people will change their opinion about an opcode if you build [activation= =20 > client][2] or a different table. If you read all the rationales, its not= =20 > just me who finds this opcode irrelevant. Please respect the developers w= ho=20 > shared their evaluations in the table even if you disagree with them. If= =20 > you cannot appreciate efforts to review proposals and reach technical=20 > consensus, at least avoid calling reviews/evaluations as "voting". > >=20 > > "Unnecessary" because LN symmetry (efficient) is possible without it.= =20 > "Complexity" is introduced because it will be used for everything possibl= e=20 > with it in bitcoin script and not just the use cases described in your=20 > email. > >=20 > > /dev/fd0 > > floppy disk guy > >=20 > > [1]: https://gitlab.com/-/snippets/4777553 > > [2]: https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAA= J > > On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonsettler= wrote: > >=20 > > > Hi Floppy, > > >=20 > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does.= =20 > They make it more efficient, and they also help other contracts. > > > Among them: Resumeable LN channels, Multi-party LN channels, Vaults,= =20 > etc. > > >=20 > > > Main benefit for the network: we can reduce the number of SigOps=20 > on-chain which benefits everyone that runs a validating node by making it= =20 > more economic to use a single signature for multiple elements instead of= =20 > using something like the ReKey technique. > > >=20 > > > Calling it "unnecessary complexity" is not a valid technical=20 > observation in any shape or form. It would provide optimization for many= =20 > contracts and use cases even if we had CAT. I explained this to you in=20 > private first, yet you keep insisting on this completely invalid objectio= n. > > >=20 > > > BR, > > > moonsettler > > >=20 > > > PS: I largely agree with everything Ethan said. > > >=20 > > > Sent with Proton Mail secure email. > > >=20 > > > On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 < > alice...@gmail.com> wrote: > > >=20 > > > > Hi Ethan, > > > > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas= =20 > OP_PAIRCOMMIT is a part of LNHANCE. > > > > > > > > In this context, OP_PAIRCOMMIT adds unnecessary complexity because= =20 > LN SYMMETRY can be achieved with other opcodes. > > > > > > > > Note: The objections shared in this thread are a summarised version= =20 > of all the rationales and not my person opinion. > > > > > > > > /dev/fd0 > > > > floppy disk guy > > > > > > > > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman =20 > wrote: > > > > > > > > > One of the CAT authors here > > > > > > > > > > > > [PAIR_COMMIT] Adds unnecessary complexity > > > > > > That's a subjective value judgement it enables something that= =20 > was no possible before which is interacting with Merkle trees and=20 > multi-element commitments in script. PAIRCOMMIT is not significantly more= =20 > complicated than CAT, and in a lot of actual use cases CAT was desired fo= r=20 > it's more complex and resource intensive to safely use CAT than PAIRCOMMI= T=20 > due to witness malleability. > > > > > > > > > > PAIR_COMMIT (BIP-442) for all intents and purposes is as simple i= n > > > > > 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 fo= r=20 > PAIRCOMMIT. > > > > > > > > > > The rationale for PAIRCOMMIT rests on the assumption that the=20 > Bitcoin > > > > > community does not want the expressiveness of CAT. If we assume= =20 > this > > > > > is the case, then we should be very careful PAIRCOMMIT does not= =20 > enable > > > > > this expressiveness as well. On the other hand, if the Bitcoin > > > > > community does want the expressiveness of CAT, then we should mer= ge > > > > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT= =20 > and it > > > > > is likely that you can not simulate CAT with PAIRCOMMIT. That=20 > said, I > > > > > am not convinced it is impossible that there is no way to simulat= e=20 > CAT > > > > > with PAIRCOMMIT, nor I do feel confident that I know how much les= s > > > > > 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 reall= y > > > > > understand the limits of PAIRCOMMIT. For instance can you do=20 > arbitrary > > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If= =20 > not, > > > > > why not? > > > > > > > > > > That said, I have not heard any argument against PAIRCOMMIT from= =20 > 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= =20 > Development > > > > > Mailing List wrote: > > > > > > > > > > > > Hi All, > > > > > > > > > > > > One thing I would like to make clear before people get the wron= g=20 > idea and think this is some form of voting, OP_INTERNALKEY and OP_PARCOMM= IT=20 > is part of LNhance and will be part of the activation client we release= =20 > soon. The only way to change that is to demonstrate actual harm. You liki= ng=20 > something else more, is your problem. What you can do about it, is write= =20 > your activation client and try to gain consensus on that. There are plent= y=20 > of version bits available. Replacing PAIRCOMMIT with CAT would be really= =20 > easy, but while CAT is indeed very popular and has a wide support base it= =20 > is also strongly opposed by many who did not choose to participate. I'm n= ot=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 > > > > > > =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= =20 > means. Literally nobody managed to come up with a single use case anyone= =20 > worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No"= =20 > from 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= =20 > was no possible before which is interacting with Merkle trees and=20 > multi-element commitments in script. PAIRCOMMIT is not significantly more= =20 > complicated than CAT, and in a lot of actual use cases CAT was desired fo= r=20 > it's more complex and resource intensive to safely use CAT than PAIRCOMMI= T=20 > due to witness malleability. > > > > > > > > > > > > > Not convinced it is impossible that there is no way to=20 > simulate CAT with PAIRCOMMIT, nor confident how much less powerful=20 > 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, > > > > > > > > > > > > > > I had shared covenants support wiki page link here on [mailin= g=20 > list][1] in the last week of November 2024. Multiple changes were made=20 > based on the feedback: > > > > > > > > > > > > > > - Removed 'community support' from 'No'. Rephrased definition= s=20 > 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 rational= e. > > > > > > > > > > > > > > Murch and Gloria shared their feedback in the bitcoin optech= =20 > [podcast 333][2]. I have started working on a [page][3] that lists use=20 > cases, prototype links and primitives used. We can still add more use cas= es=20 > in it. This list does not include use cases enabled by=20 > [OP_CHECKSIGFROMSTACK][4] alone or in combination with other opcodes like= =20 > [LN SYMMETRY][5]. > > > > > > > > > > > > > > I had verified each entry to avoid spam and fake evaluations.= =20 > Rearden was assigned moderator permissions on 8 December 2024 by Theymos = to=20 > help me with the moderations. Some edits have been approved by other=20 > moderators. > > > > > > > > > > > > > > Some insights from the table that could help developers=20 > working on different covenant proposals: > > > > > > > > > > > > > > 1. Multiple ways to achieve LN symmetry were discovered.=20 > SIGHASH_APO lacks interest among developers, contrary to the belief prior= =20 > to this exercise. > > > > > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part o= f=20 > multiple covenant proposals. > > > > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY= =20 > are not reviewed by enough developers. OP_PARCOMMIT seems to be=20 > 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=20 > which is more efficient. Its not the best option for covenants and cannot= =20 > be used to improve Ark. Some developers prefer opcodes and not sighash=20 > flags. > > > > > > > > > > > > > > Seems to be the result of an attempt to fix signatures to mak= e=20 > them work for a specific use-case, but the end-result is hard-to-reason= =20 > (for me) and not flexible. In general, SIGHASH flags are an encoding of= =20 > specific predicates on the transaction, and I think the Script is better= =20 > suited to carry the predicate. There is no interesting SIGHASH flag that= =20 > couldn't be functionally simulated by introspection + CHECKSIGFROMSTACK (= or=20 > other Script-based approaches), and that seems to me a much cleaner and= =20 > ergonomic way to achieve the same goals. > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > OP_TXHASH > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > > > > > > > > More expressive, many flag configurations, untested and=20 > undesirable use cases. Unaddressed comments in the BIP and the delay=20 > doesn't make sense because OP_CHECKTEMPLATEVERIFY can be upgraded later t= o=20 > achieve the same thing. Makes hash caching complex, potentially opening u= p=20 > DoS vectors or quadratic sighash. > > > > > > > > > > > > > > Most templates you'd obtain with various combinations of=20 > parameters are meaningless. It implements state-carrying UTXOs in a very= =20 > dirty way: adding additional inputs/outputs with no other meaning than=20 > "storing some state". This is ugly, inefficient, and bloats the UTXO set = -=20 > and it definitely will happen if TXHASH is enabled without also enabling = a=20 > clean way to carry state. > > > > > > > > > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine= =20 > tune it to what people are actually using covenants for, instead of=20 > 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= =20 > use cases (DEX, AMM and Hashrate Escrow). Enables granular transaction=20 > introspection through abuse of schnorr signatures and OP_CHECKSIG. Can be= =20 > used for interesting use cases but alone does it poorly and inefficiently= . > > > > > > > > > > > > > > People can and will litter the chain with inefficient/ugly=20 > Scripts if activated alone. Since it happens to enable generic=20 > introspection by accident, and therefore an ugly version of state-carryin= g=20 > UTXOs, it shouldn't be enabled without more ergonomic opcodes for those u= se=20 > 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=20 > 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= =20 > in future and added for specific use case. LN SYMMETRY is possible withou= t=20 > this opcode. It does not compose with anything that involves transaction= =20 > introspection due to its specified tagged hash. Some developers prefer=20 > OP_CAT. > > > > > > > > > > > > > > Not convinced it is impossible that there is no way to=20 > simulate CAT with PAIRCOMMIT, nor confident how much less powerful=20 > 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=20 > summary and approving edits. There are a few things that I want to share= =20 > and it could be a result of the aggressive marketing: > > > > > > > > > > > > > > - A spammer had edited the table to remove all evaluations=20 > except in favor of OP_CAT and it was rejected. > > > > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention=20 > anything about other opcodes and SIGHASH_APO. It is only focused on OP_CA= T=20 > however evaluations exist in the table. > > > > > > > - I [requested][7] Udev (CatSwap) to add details about=20 > evaluation of other opcodes and SIGHASH_APO. > > > > > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with= =20 > incorrect signet stats and seems to be rephrased version of another=20 > rationale. Evaluation had 'weak' for OP_CTV before adding the rationale. > > > > > > > - An edit with duplicate rationale (in support of OP_CAT) was= =20 > rejected because sharing the link for a rationale submitted by other=20 > developer adds no value in the table. > > > > > > > > > > > > > > Evaluations without a rationale have some 'No' in different= =20 > cells. Although none of them are backed by a rationale so cannot be=20 > considered for consensus discussion. The table is still updated regularly= =20 > so you may see some of them with a rationale in 2025. Any suggestions to= =20 > 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=20 > evaluations in the table and everyone who shared updates on twitter. It w= as=20 > a coordinated effort to reach some technical consensus. You can read all= =20 > the rationales in detail to understand different perspectives and reasons= =20 > to support a combination of opcodes over others. > > > > > > > > > > > > > > [1]:=20 > 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]:=20 > https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7 > > > > > > > [6]:=20 > 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 > > > > > > > > > > > > > > /dev/fd0 > > > > > > > floppy disk guy > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the= =20 > Google Groups "Bitcoin Development Mailing List" group. > > > > > > > To unsubscribe from this group and stop receiving emails from= =20 > it, send 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 > . > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the=20 > Google Groups "Bitcoin Development Mailing List" group. > > > > > > To unsubscribe from this group and stop receiving emails from= =20 > it, send an email to bitcoindev+...@googlegroups.com. > > > > > > To view this discussion visit=20 > 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 Googl= e=20 > Groups "Bitcoin Development Mailing List" group. > > > > > To unsubscribe from this group and stop receiving emails from it,= =20 > send an email to bitcoindev+...@googlegroups.com. > > > > > To view this discussion visit=20 > 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=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/c411dee9-1937-42fd-bc66-d347= ddbff506n%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/= c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com. ------=_Part_534799_1161673789.1736864077681 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have been discussing the objections shared by Jonas Nick in his rational= e: https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4b5a51

Feel free to comment if you'd like to add something.

/dev/fd0
floppy disk guy

On Friday, Ja= nuary 3, 2025 at 5:45:29=E2=80=AFPM UTC+5:30 moonsettler wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left:= 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi FLoppy,

Of course I appreciate thoughtful evaluations.

But my point stands, I encourage everyone to look at this table as mean= s to engage in discussion not some indicator of "consensus" by an= y means.

And I emphasized this, because there was a weird perception emerging, a= nd even your own summary had this feel to it.

BR,
moonsettler


Sent with Proton Mail secure email.

On Thursday, January 2nd, 2025 at 4:16 PM, /dev /fd0 <alice...@gmail.com> wrote:

> Hi moonsettler,
> > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhan= ce does. They make it more efficient, and they also help other contracts.
> Among them: Resumeable LN channels, Multi-party LN channels, Vault= s, etc.
>=20
> I am aware of this and have used the comparison table in my [ratio= nale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
>=20
> > Calling it "unnecessary complexity" is not a valid = technical observation in any shape or form. It would provide optimization f= or many contracts and use cases even if we had CAT. I explained this to you= in private first, yet you keep insisting on this completely invalid object= ion.
>=20
> It is a valid objection and I find it disappointing that you think= people will change their opinion about an opcode if you build [activation = client][2] or a different table. If you read all the rationales, its not ju= st me who finds this opcode irrelevant. Please respect the developers who s= hared their evaluations in the table even if you disagree with them. If you= cannot appreciate efforts to review proposals and reach technical consensu= s, at least avoid calling reviews/evaluations as "voting".
>=20
> "Unnecessary" because LN symmetry (efficient) is possibl= e without it. "Complexity" is introduced because it will be used = for everything possible with it in bitcoin script and not just the use case= s described in your email.
>=20
> /dev/fd0
> floppy disk guy
>=20
> [1]: https://gi= tlab.com/-/snippets/4777553
> [2]: https://groups.google.co= m/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ
> On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonse= ttler wrote:
>=20
> > Hi Floppy,
> >=20
> > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhan= ce does. They make it more efficient, and they also help other contracts.
> > Among them: Resumeable LN channels, Multi-party LN channels, = Vaults, etc.
> >=20
> > Main benefit for the network: we can reduce the number of Sig= Ops on-chain which benefits everyone that runs a validating node by making = it more economic to use a single signature for multiple elements instead of= using something like the ReKey technique.
> >=20
> > Calling it "unnecessary complexity" is not a valid = technical observation in any shape or form. It would provide optimization f= or many contracts and use cases even if we had CAT. I explained this to you= in private first, yet you keep insisting on this completely invalid object= ion.
> >=20
> > BR,
> > moonsettler
> >=20
> > PS: I largely agree with everything Ethan said.
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 <alice...@gmail.com> wrote:
> >=20
> > > Hi Ethan,
> > > OP_CAT is not proposed as an opcode to enable LN SYMMETR= Y. Whereas OP_PAIRCOMMIT is a part of LNHANCE.
> > >
> > > In this context, OP_PAIRCOMMIT adds unnecessary complexi= ty because LN SYMMETRY can be achieved with other opcodes.
> > >
> > > Note: The objections shared in this thread are a summari= sed 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 <eth...@gmail.com> wrote:
> > >
> > > > One of the CAT authors here
> > > >
> > > > > > [PAIR_COMMIT] Adds unnecessary complexity
> > > > > That's a subjective value judgement it ena= bles something that was no possible before which is interacting with Merkle= trees and multi-element commitments in script. PAIRCOMMIT is not significa= ntly more complicated than CAT, and in a lot of actual use cases CAT was de= sired for it's more complex and resource intensive to safely use CAT th= an 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 technica= l objection to
> > > > PAIRCOMMIT and it provides much needed functionalit= y.
> > > >
> > > > My primary concern is not PAIRCOMMIT itself, but th= e rationale for PAIRCOMMIT.
> > > >
> > > > The rationale for PAIRCOMMIT rests on the assumptio= n that the Bitcoin
> > > > community does not want the expressiveness of CAT. = If we assume this
> > > > is the case, then we should be very careful PAIRCOM= MIT 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 express= ive than CAT and it
> > > > is likely that you can not simulate CAT with PAIRCO= MMIT. 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 kno= w 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 c= an you do arbitrary
> > > > computation by building STARKs with PAIRCOMMIT merk= le trees? If not,
> > > > why not?
> > > >
> > > > That said, I have not heard any argument against PA= IRCOMMIT from those
> > > > against CAT, so perhaps they are comfortable with i= t.
> > > >
> > > > Since I am in favor of CAT, I am also in favor of P= AIRCOMMIT.
> > > >
> > > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonse= ttler' via Bitcoin Development
> > > > Mailing List <bitco...@googlegroups.com> wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > One thing I would like to make clear before pe= ople get the wrong idea and think this is some form of voting, OP_INTERNALK= EY and OP_PARCOMMIT is part of LNhance and will be part of the activation c= lient 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 abo= ut it, is write your activation client and try to gain consensus on that. T= here are plenty of version bits available. Replacing PAIRCOMMIT with CAT wo= uld be really easy, but while CAT is indeed very popular and has a wide sup= port base it is also strongly opposed by many who did not choose to partici= pate. I'm not convinced that this table represents actual developer, le= t alone ecosystem consensus. If you decide you want to run an alternative a= ctivation 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 singl= e use case anyone worth noting objects to for PAIRCOMMIT. Also inclined to = ignore the "No" from those that prefer CAT as plain trolling. Thi= s BIP is young, there is a clear correlation between the age of the proposa= ls and their support with the sole exception of APO.
> > > > >
> > > > > > Adds unnecessary complexity
> > > > >
> > > > > That's a subjective value judgement it ena= bles something that was no possible before which is interacting with Merkle= trees and multi-element commitments in script. PAIRCOMMIT is not significa= ntly more complicated than CAT, and in a lot of actual use cases CAT was de= sired for it's more complex and resource intensive to safely use CAT th= an 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 pow= erful 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, /d= ev /fd0 <alice...@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' fro= m 'No'. Rephrased definitions for 'Prefer' and 'Evaluat= ing'.
> > > > > > - Added LNHANCE category for a combinatio= n of opcodes.
> > > > > > - Added links for BIP drafts and a column= for 'rationale'.
> > > > > > - Created a separate table for evaluation= s 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 ad= d more use cases in it. 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 a= nd fake evaluations. Rearden was assigned moderator permissions on 8 Decemb= er 2024 by Theymos to help me with the moderations. Some edits have been ap= proved by other moderators.
> > > > > >
> > > > > > Some insights from the table that could h= elp developers working on different covenant proposals:
> > > > > >
> > > > > > 1. Multiple ways to achieve LN symmetry w= ere discovered. SIGHASH_APO lacks interest among developers, contrary to th= e belief prior to this exercise.
> > > > > > 2. OP_CHECKSIGFROMSTACK has unanimous sup= port and is a part of multiple covenant proposals.
> > > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_C= HECKCONTRACTVERIFY are not reviewed by enough developers. OP_PARCOMMIT seem= s 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 coven= ants and cannot be used to improve Ark. Some developers prefer opcodes and = not sighash flags.
> > > > > >
> > > > > > Seems to be the result of an attempt to f= ix signatures to make them work for a specific use-case, but the end-result= is hard-to-reason (for me) and not flexible. In general, SIGHASH flags are= an encoding of specific predicates on the transaction, and I think the Scr= ipt is better suited to carry the predicate. There is no interesting SIGHAS= H flag that couldn't be functionally simulated by introspection + CHECK= SIGFROMSTACK (or other Script-based approaches), and that seems to me a muc= h cleaner and ergonomic way to achieve the same goals.
> > > > > >
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > OP_TXHASH
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > >
> > > > > > More expressive, many flag configurations= , untested and undesirable use cases. Unaddressed comments in the BIP and t= he delay doesn't make sense because OP_CHECKTEMPLATEVERIFY can be upgra= ded later to achieve the same thing. Makes hash caching complex, potentiall= y opening up DoS vectors or quadratic sighash.
> > > > > >
> > > > > > Most templates you'd obtain with vari= ous combinations of parameters are meaningless. It implements state-carryin= g UTXOs in a very dirty way: adding additional inputs/outputs with no other= meaning than "storing some state". This is ugly, inefficient, an= d 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_CHECKTEMP= LATEVERIFY 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 sp= ecific 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 i= ncluding undesirable use cases (DEX, AMM and Hashrate Escrow). Enables gran= ular transaction introspection through abuse of schnorr signatures and OP_C= HECKSIG. 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 ge= neric introspection by accident, and therefore an ugly version of state-car= rying 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 in= volves transaction introspection due to its specified tagged hash. Some dev= elopers prefer OP_CAT.
> > > > > >
> > > > > > Not convinced it is impossible that there= is no way to simulate CAT with PAIRCOMMIT, nor confident how much less pow= erful 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 i= n writing this summary and approving edits. There are a few things that I w= ant to share and it could be a result of the aggressive marketing:
> > > > > >
> > > > > > - A spammer had edited the table to remov= e 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 f= ocused 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 versi= on of another rationale. Evaluation had 'weak' for OP_CTV before ad= ding the rationale.
> > > > > > - An edit with duplicate rationale (in su= pport of OP_CAT) was rejected because sharing the link for a rationale subm= itted by other developer adds no value in the table.
> > > > > >
> > > > > > Evaluations without a rationale have some= 'No' in different cells. Although none of them are backed by a rat= ionale so cannot be considered for consensus discussion. The table is still= updated regularly so you may see some of them with a rationale in 2025. An= y 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 thei= r opinion
> > > > > > - Build activation client and discuss par= ameters
> > > > > >
> > > > > > Finally, I would thank all the developers= who added their evaluations in the table and everyone who shared updates o= n twitter. It was a coordinated effort to reach some technical consensus. Y= ou can read all the rationales in detail to understand different perspectiv= es 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/bitco= in/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/b768d20d6254992= 2b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5359072
> > > > > > [8]: https://en.bitcoin.it/w/ind= ex.php?title=3DCovenants_support&diff=3Dprev&oldid=3D70520
> > > > > >
> > > > > > /dev/fd0
> > > > > > floppy disk guy
> > > > > >
> > > > > > --
> > > > > > You received this message because you are= subscribed to the Google Groups "Bitcoin Development Mailing List&quo= t; group.
> > > > > > To unsubscribe from this group and stop r= eceiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/38a6f252-a= fe9-4155-a341-11a42a9a9007n%40googlegroups.com.
> > > > >
> > > > > --
> > > > > You received this message because you are subs= cribed to the Google Groups "Bitcoin Development Mailing List" gr= oup.
> > > > > To unsubscribe from this group and stop receiv= ing emails from it, send an email to bitcoindev+...@googlegroups.com.
> > > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweI= hzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtM= WXXV2frBWXac%3D%40protonmail.com.
> > > >
> > > > --
> > > > You received this message because you are subscribe= d to the Google Groups "Bitcoin Development Mailing List" group.
> > > > To unsubscribe from this group and stop receiving e= mails from it, send an email to = bitcoindev+...@googlegroups.com.
> > > > To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7= DBaA%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 email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff50= 6n%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/c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com.
------=_Part_534799_1161673789.1736864077681-- ------=_Part_534798_751735772.1736864077681--