From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 02 Jan 2025 07:42:36 -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 1tTNLG-00016F-Km for bitcoindev@gnusha.org; Thu, 02 Jan 2025 07:42:36 -0800 Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e4a8b40dd40sf22441636276.3 for ; Thu, 02 Jan 2025 07:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735832548; x=1736437348; 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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=; b=FHUGF0Dv8PZBZrbfRrKpDRv0HoHCSKHApOZgcKkMSDi0ZG88DUteCTJxYUm8+4AmJv 93OzBQRvs3tsiAW/KwYa38qvcczSW2c4F0JDvF+sgI9w9fiiZO1xcFAqm+Ti7vxF2gKD i3YQuXh/MTkeTqEytLvHnKYn36VO87JbTrJULPFGFT4NK51pv6KLP3a8K9OyyI0k0L+O JO/AlQCozLLF7sku3v5Vf3/gCbKF3ynFPg8HSxd/m51jWxWnyi4/E6PJcysuXW1tFSoz Gns8qIUazMWhBU/l2bC1JYmMhvlo9+oexMHkKmIo62h39Z55LiW7dixaJ9cN43e1b8Y9 mpQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735832548; x=1736437348; 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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=; b=D7e5E2+OP9aeQ7223ni7NBCcajbrQap5gr3ObLM/IvPilYWc2m/H1I+b+p6Eqt8BN5 e4eMk6rxIxu1zdL9ZUXqGFC8MpDMh/FyDu9ncVQHKgLTF6kthOsgUBHHw8zdIdzbXrmM qgkh6a+MQrawqvki9pt1Z6E80wN382DKT2DSU7jhOXPEwMt2fT5oeWs4KKZskJJ+eSxT rlGUE/UD69p2N5zXaRM5KHEjic9nNedXcz1SfAGYCULc6vdN8FTxjZk2lgwYE7WiZMHX ybbcUHCaeDq8G8jh4baMiahaMaJ/gn5JXSePt4ZEBcTLx0weU1kJUSa5MNA0zqC2rNQy i7qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735832548; x=1736437348; 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=UsZEQDxQu+yYvuaDH8rUb0lR/qdD2FRicbIq7ojy0q8=; b=rUW0LdA2cHy2f8CgwZbREKLdMNfAwNa8OFxlOk6GCXJPFFf7OyiwX9XBblggZ09BtC nN+c1erCXrMQ+ENicJj7U/ArWXPKptBldPSk9c/A96Z1wRyMz9KTYWZ04824B9RLITza Cp8nTS0JliWyhnJN6Bz1sf4gcxr0ey7Un1fAMn5uaIyukjj8FPn6qUMItTKQNKRg/8sk 12ygc5K9wPZpUu8RFuVaUOT6SOEA4yCCRBtxwxGzhJAoG0Vu56QDkC3wGZvK9wmSqRJE HI/E/1jRXkjkD3qIWk0xq28uozTwjIzMz28SCHj/YPsZ3BFbL9z16hvEgE48s0Z3aKea ciig== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUQNkpRWjG3wFDeyp4WTI70cVBePSxq3fmBX6Jw7yAaPwGr1oyZGNrEnFglKeXdxpvQEQFh4kR5JFpw@gnusha.org X-Gm-Message-State: AOJu0YyFBPpjqDDVR04sD/YGZfElfnj/M8QkhS2aJ78ePCayRbxOnMOd FD7Glr9SBDhotWjMcBzSwP2iXkT6CMiGEUcbmH1XCZPZ7xb1+449 X-Google-Smtp-Source: AGHT+IH8N+Bop32PEtfw+6UbwN4J7bznLeEg9y3F4HbopimiJDzesjlVoLQeBGDbdfjCMfX9r+oZnQ== X-Received: by 2002:a25:1f87:0:b0:e3c:a022:b53a with SMTP id 3f1490d57ef6-e538c287c14mr21191019276.28.1735832547851; Thu, 02 Jan 2025 07:42:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:a1a3:0:b0:e48:8566:cdf0 with SMTP id 3f1490d57ef6-e548058dae3ls64385276.1.-pod-prod-02-us; Thu, 02 Jan 2025 07:42:25 -0800 (PST) X-Received: by 2002:a05:690c:734a:b0:6ef:8dd0:fff9 with SMTP id 00721157ae682-6f3f80d60a5mr331050387b3.8.1735832544973; Thu, 02 Jan 2025 07:42:24 -0800 (PST) Received: by 2002:a05:690c:b10:b0:6ef:9b37:85ef with SMTP id 00721157ae682-6f484ea9c5ams7b3; Thu, 2 Jan 2025 07:16:43 -0800 (PST) X-Received: by 2002:a05:690c:6505:b0:6ef:97a2:49ef with SMTP id 00721157ae682-6f3f80d18f5mr363733247b3.8.1735831001971; Thu, 02 Jan 2025 07:16:41 -0800 (PST) Date: Thu, 2 Jan 2025 07:16:41 -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_1145794_2009645589.1735831001709" 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_1145794_2009645589.1735831001709 Content-Type: multipart/alternative; boundary="----=_Part_1145795_1600931531.1735831001709" ------=_Part_1145795_1600931531.1735831001709 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, etc. I am aware of this and have used the comparison table in my [rationale][1].= =20 LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY. > Calling it "unnecessary complexity" is not a valid technical observation= =20 in any shape or form. It would provide optimization for many contracts and= =20 use cases even if we had CAT. I explained this to you in private first, yet= =20 you keep insisting on this completely invalid objection. It is a valid objection and I find it disappointing that you think people= =20 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 who= =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 possible= =20 with it in bitcoin script and not just the use cases described in your=20 email. /dev/fd0 floppy disk guy=20 [1]: https://gitlab.com/-/snippets/4777553 [2]: https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonsettler wro= te: > Hi Floppy, > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. The= y=20 > make it more efficient, and they also help other contracts. > Among them: Resumeable LN channels, Multi-party LN channels, Vaults, etc. > > Main benefit for the network: we can reduce the number of SigOps on-chain= =20 > which benefits everyone that runs a validating node by making it more=20 > economic to use a single signature for multiple elements instead of using= =20 > something like the ReKey technique. > > Calling it "unnecessary complexity" is not a valid technical observation= =20 > in any shape or form. It would provide optimization for many contracts an= d=20 > use cases even if we had CAT. I explained this to you in private first, y= et=20 > you keep insisting on this completely invalid objection. > > BR, > moonsettler > > PS: I largely agree with everything Ethan said. > > Sent with Proton Mail secure email. > > On Thursday, January 2nd, 2025 at 2:22 AM, /dev /fd0 = =20 > wrote: > > > Hi Ethan, > > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas=20 > OP_PAIRCOMMIT is a part of LNHANCE. > >=20 > > In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN= =20 > SYMMETRY can be achieved with other opcodes. > >=20 > > Note: The objections shared in this thread are a summarised version of= =20 > all the rationales and not my person opinion. > >=20 > > /dev/fd0 > > floppy disk guy > >=20 > > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman wrote: > >=20 > > > One of the CAT authors here > > >=20 > > > > > [PAIR_COMMIT] Adds unnecessary complexity > > > > That's a subjective value judgement it enables something that was n= o=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. > > >=20 > > > PAIR_COMMIT (BIP-442) for all intents and purposes is as simple in > > > implementation at CAT (BIP-347). I have no technical objection to > > > PAIRCOMMIT and it provides much needed functionality. > > >=20 > > > My primary concern is not PAIRCOMMIT itself, but the rationale for=20 > PAIRCOMMIT. > > >=20 > > > The rationale for PAIRCOMMIT rests on the assumption that the Bitcoin > > > community does not want the expressiveness of CAT. If we assume this > > > is the case, then we should be very careful PAIRCOMMIT does not enabl= e > > > this expressiveness as well. On the other hand, if the Bitcoin > > > community does want the expressiveness of CAT, then we should merge > > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT and i= t > > > is likely that you can not simulate CAT with PAIRCOMMIT. That said, I > > > am not convinced it is impossible that there is no way to simulate CA= T > > > with PAIRCOMMIT, nor I do feel confident that I know how much less > > > powerful PAIRCOMMIT is than CAT. > > >=20 > > > Playing devil's advocate for a second, if I was opposed to CAT on > > > grounds that we should limit expressiveness I would want to really > > > understand the limits of PAIRCOMMIT. For instance can you do arbitrar= y > > > computation by building STARKs with PAIRCOMMIT merkle trees? If not, > > > why not? > > >=20 > > > That said, I have not heard any argument against PAIRCOMMIT from thos= e > > > against CAT, so perhaps they are comfortable with it. > > >=20 > > > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT. > > >=20 > > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitcoin Dev= elopment > > > Mailing List wrote: > > > > > > > > Hi All, > > > > > > > > One thing I would like to make clear before people get the wrong=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 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 n= o=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= =20 > CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is= =20 > 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 [mailing=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 definitions fo= r=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. > > > > > > > > > > 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 working o= n=20 > 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 of=20 > multiple covenant proposals. > > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are= =20 > not reviewed by enough developers. OP_PARCOMMIT seems to be controversial= =20 > 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 i= s=20 > more efficient. Its not the best option for covenants and cannot be used = to=20 > improve Ark. Some developers prefer opcodes and not sighash flags. > > > > > > > > > > Seems to be the result of an attempt to fix signatures to make=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 tune= =20 > it to what people are actually using covenants for, instead of prematurel= y=20 > optimizing everything with no data. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > OP_VAULT > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > > > No demand for vaults. Customized for a specific use case. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > OP_CAT > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > > > Can be used for various complex scripts including undesirable use= =20 > 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 Script= s=20 > if 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. > > > > > > > > > > =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= =20 > 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= =20 > future and added for specific use case. LN SYMMETRY is possible without= =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 simulate= =20 > CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is= =20 > than CAT. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > OP_CHECKTEMPLATEVERIFY > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > > > Limited in scope and not recursive. > > > > > ``` > > > > > > > > > > I have tried my best to remain unbiased in writing this summary= =20 > and approving edits. There are a few things that I want to share and it= =20 > could be a result of the aggressive marketing: > > > > > > > > > > - A spammer had edited the table to remove all evaluations except= =20 > in favor of OP_CAT and it was rejected. > > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention anythin= g=20 > about 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= =20 > 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 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. > > > > > > > > > > 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 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/38a6f252-afe9-4155-a341-11a4= 2a9a9007n%40googlegroups.com > . > > > > > > > > -- > > > > 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,= =20 > 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 > . > > >=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, sen= d=20 > 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 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/= c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com. ------=_Part_1145795_1600931531.1735831001709 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi moonsettler,

>=C2=A0 Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. They = make it more efficient, and they also help other contracts.
Among them= : Resumeable LN channels, Multi-party LN channels, Vaults, etc.

= I am aware of this and have used the comparison table in my [rationale][1].= LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.

>= =C2=A0 Calling it "unnecessary complexity" is not a valid technical observation in= any shape or form. It would provide optimization for many contracts and us= e cases even if we had CAT. I explained this to you in private first, yet y= ou keep insisting on this completely invalid objection.

It is a = valid objection and I find it disappointing that you think people will chan= ge their opinion about an opcode if you build [activation client][2] or a d= ifferent table. If you read all the rationales, its not just me who finds t= his opcode irrelevant. Please respect the developers who shared their evalu= ations in the table even if you disagree with them. If you cannot appreciat= e efforts to review proposals and reach technical consensus, at least avoid= calling reviews/evaluations as "voting".=C2=A0

"Unnecessary" be= cause LN symmetry (efficient) is possible without it. "Complexity" is intro= duced because it will be used for everything possible with it in bitcoin sc= ript and not just the use cases described in your email.

/dev/fd0
floppy disk guy=C2=A0

[1]:=C2=A0https://g= itlab.com/-/snippets/4777553
[2]:=C2=A0https://groups.google.com/g/bit= coindev/c/QOnpM4Ixmms/m/eodYc71lDAAJ
On Thursday, January 2, 2025 at 7:16:55=E2= =80=AFPM UTC+5:30 moonsettler wrote:
Hi Floppy,

Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. T= hey make it more efficient, and they also help other contracts.
Among them: Resumeable LN channels, Multi-party LN channels, Vaults, et= c.

Main benefit for the network: we can reduce the number of SigOps on-cha= in which benefits everyone that runs a validating node by making it more ec= onomic to use a single signature for multiple elements instead of using som= ething like the ReKey technique.

Calling it "unnecessary complexity" is not a valid technical = observation in any shape or form. It would provide optimization for many co= ntracts and use cases even if we had CAT. I explained this to you in privat= e first, yet you keep insisting on this completely invalid objection.

BR,
moonsettler

PS: I largely agree with everything Ethan said.

Sent with Proton Mail secure email.

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

> Hi Ethan,
> OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas= OP_PAIRCOMMIT is a part of LNHANCE.
>=20
> In this context, OP_PAIRCOMMIT adds unnecessary complexity because= LN SYMMETRY can be achieved with other opcodes.
>=20
> Note: The objections shared in this thread are a summarised versio= n of all the rationales and not my person opinion.
>=20
> /dev/fd0
> floppy disk guy
>=20
> On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth...@gmail.com> wrote:
>=20
> > One of the CAT authors here
> >=20
> > > > [PAIR_COMMIT] Adds unnecessary complexity
> > > That's a subjective value judgement it enables somet= hing that was no possible before which is interacting with Merkle trees and= multi-element commitments in script. PAIRCOMMIT is not significantly more = complicated than CAT, and in a lot of actual use cases CAT was desired for = it's more complex and resource intensive to safely use CAT than PAIRCOM= MIT due to witness malleability.
> >=20
> > PAIR_COMMIT (BIP-442) for all intents and purposes is as simp= le in
> > implementation at CAT (BIP-347). I have no technical objectio= n to
> > PAIRCOMMIT and it provides much needed functionality.
> >=20
> > My primary concern is not PAIRCOMMIT itself, but the rational= e for PAIRCOMMIT.
> >=20
> > The rationale for PAIRCOMMIT rests on the assumption that the= Bitcoin
> > community does not want the expressiveness of CAT. If we assu= me this
> > is the case, then we should be very careful PAIRCOMMIT does n= ot enable
> > this expressiveness as well. On the other hand, if the Bitcoi= n
> > community does want the expressiveness of CAT, then we should= merge
> > CAT. PAIRCOMMIT is well designed to be less expressive than C= AT and it
> > is likely that you can not simulate CAT with PAIRCOMMIT. That= said, I
> > am not convinced it is impossible that there is no way to sim= ulate CAT
> > with PAIRCOMMIT, nor I do feel confident that I know how much= less
> > powerful PAIRCOMMIT is than CAT.
> >=20
> > Playing devil's advocate for a second, if I was opposed t= o CAT on
> > grounds that we should limit expressiveness I would want to r= eally
> > understand the limits of PAIRCOMMIT. For instance can you do = arbitrary
> > computation by building STARKs with PAIRCOMMIT merkle trees? = If not,
> > why not?
> >=20
> > That said, I have not heard any argument against PAIRCOMMIT f= rom those
> > against CAT, so perhaps they are comfortable with it.
> >=20
> > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.
> >=20
> > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler'= via Bitcoin Development
> > Mailing List <b= itco...@googlegroups.com> wrote:
> > >
> > > Hi All,
> > >
> > > One thing I would like to make clear before people get t= he wrong idea and think this is some form of voting, OP_INTERNALKEY and OP_= PARCOMMIT is part of LNhance and will be part of the activation client we r= elease soon. The only way to change that is to demonstrate actual harm. You= liking something else more, is your problem. What you can do about it, is = write your activation client and try to gain consensus on that. There are p= lenty of version bits available. Replacing PAIRCOMMIT with CAT would be rea= lly easy, but while CAT is indeed very popular and has a wide support base = it is also strongly opposed by many who did not choose to participate. I= 9;m not convinced that this table represents actual developer, let alone ec= osystem consensus. If you decide you want to run an alternative activation = effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> > > OP_PARCOMMIT
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> > >
> > > > OP_PARCOMMIT seems to be controversial at this mome= nt.
> > >
> > > I strongly disagree. In my book that's not what cont= roversial means. Literally nobody managed to come up with a single use case= anyone worth noting objects to for PAIRCOMMIT. Also inclined to ignore the= "No" from those that prefer CAT as plain trolling. This BIP is y= oung, there is a clear correlation between the age of the proposals and the= ir support with the sole exception of APO.
> > >
> > > > Adds unnecessary complexity
> > >
> > > That's a subjective value judgement it enables somet= hing that was no possible before which is interacting with Merkle trees and= multi-element commitments in script. PAIRCOMMIT is not significantly more = complicated than CAT, and in a lot of actual use cases CAT was desired for = it's more complex and resource intensive to safely use CAT than PAIRCOM= MIT due to witness malleability.
> > >
> > > > Not convinced it is impossible that there is no way= to simulate CAT with PAIRCOMMIT, nor confident how much less powerful PAIR= COMMIT 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&q= uot;.
> > >
> > > BR,
> > > moonsettler
> > >
> > >
> > > On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 &l= t;alice...@gmail.com> wro= te:
> > >
> > > > 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 we= re made based on the feedback:
> > > >
> > > > - Removed 'community support' from 'No&= #39;. Rephrased definitions for 'Prefer' and 'Evaluating'.
> > > > - Added LNHANCE category for a combination of opcod= es.
> > > > - Added links for BIP drafts and a column for '= rationale'.
> > > > - Created a separate table for evaluations without = a rationale.
> > > >
> > > > Murch and Gloria shared their feedback in the bitco= in optech [podcast 333][2]. I have started working on a [page][3] that list= s use cases, prototype links and primitives used. We can still add more use= cases in it. This list does not include use cases enabled by [OP_CHECKSIGF= ROMSTACK][4] alone or in combination with other opcodes like [LN SYMMETRY][= 5].
> > > >
> > > > I had verified each entry to avoid spam and fake ev= aluations. Rearden was assigned moderator permissions on 8 December 2024 by= Theymos to help me with the moderations. Some edits have been approved by = other moderators.
> > > >
> > > > Some insights from the table that could help develo= pers working on different covenant proposals:
> > > >
> > > > 1. Multiple ways to achieve LN symmetry were discov= ered. SIGHASH_APO lacks interest among developers, contrary to the belief p= rior to this exercise.
> > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and i= s a part of multiple covenant proposals.
> > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRA= CTVERIFY are not reviewed by enough developers. OP_PARCOMMIT seems to be co= ntroversial 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 o= pcodes which is more efficient. Its not the best option for covenants and c= annot be used to improve Ark. Some developers prefer opcodes and not sighas= h flags.
> > > >
> > > > Seems to be the result of an attempt to fix signatu= res to make them work for a specific use-case, but the end-result is hard-t= o-reason (for me) and not flexible. In general, SIGHASH flags are an encodi= ng of specific predicates on the transaction, and I think the Script is bet= ter suited to carry the predicate. There is no interesting SIGHASH flag tha= t couldn't be functionally simulated by introspection + CHECKSIGFROMSTA= CK (or other Script-based approaches), and that seems to me a much 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 the delay d= oesn'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.
> > > >
> > > > Most templates you'd obtain with various combin= ations of parameters are meaningless. It implements state-carrying UTXOs in= a very dirty way: adding additional inputs/outputs with no other meaning t= han "storing some state". This is ugly, inefficient, and bloats t= he UTXO set - and it definitely will happen if TXHASH is enabled without al= so enabling a clean way to carry state.
> > > >
> > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY= can fine tune it to what people are actually using covenants for, instead = of prematurely optimizing everything with no data.
> > > >
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > > OP_VAULT
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > >
> > > > No demand for vaults. Customized for a specific use= case.
> > > >
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > > OP_CAT
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > >
> > > > Can be used for various complex scripts including u= ndesirable use cases (DEX, AMM and Hashrate Escrow). Enables granular trans= action introspection through abuse of schnorr signatures and OP_CHECKSIG. C= an be used for interesting use cases but alone does it poorly and inefficie= ntly.
> > > >
> > > > People can and will litter the chain with inefficie= nt/ugly Scripts if activated alone. Since it happens to enable generic intr= ospection by accident, and therefore an ugly version of state-carrying UTXO= s, 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 possib= le without this opcode. It does not compose with anything that involves tra= nsaction introspection due to its specified tagged hash. Some developers pr= efer OP_CAT.
> > > >
> > > > Not convinced it is impossible that there is no way= to simulate CAT with PAIRCOMMIT, nor confident how much less powerful PAIR= COMMIT is than CAT.
> > > >
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > > OP_CHECKTEMPLATEVERIFY
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> > > >
> > > > Limited in scope and not recursive.
> > > > ```
> > > >
> > > > I have tried my best to remain unbiased in writing = this summary and approving edits. There are a few things that I want to sha= re and it could be a result of the aggressive marketing:
> > > >
> > > > - A spammer had edited the table to remove all eval= uations except in favor of OP_CAT and it was rejected.
> > > > - [Rationale][6] added by Aaron (sCrypt) does not m= ention 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 ab= out evaluation of other opcodes and SIGHASH_APO.
> > > > - Last [edit][8] by Roujiamo (bitdollar) has a rati= onale with incorrect signet stats and seems to be rephrased version of anot= her rationale. Evaluation had 'weak' for OP_CTV before adding the r= ationale.
> > > > - An edit with duplicate rationale (in support of O= P_CAT) was rejected because sharing the link for a rationale submitted by o= ther developer adds no value in the table.
> > > >
> > > > Evaluations without a rationale have some 'No&#= 39; in different cells. Although none of them are backed by a rationale so = cannot be considered for consensus discussion. The table is still updated r= egularly so you may see some of them with a rationale in 2025. Any suggesti= ons to help achieve technical consensus are most welcome.
> > > >
> > > > What's next?
> > > >
> > > > - More rationales in the table
> > > > - Discuss objections on mailing list (if any)
> > > > - Workshops
> > > > - Add a table for economic nodes and their opinion
> > > > - Build activation client and discuss parameters
> > > >
> > > > Finally, I would thank all the developers who added= their evaluations in the table and everyone who shared updates on twitter.= It was a coordinated effort to reach some technical consensus. You can rea= d all the rationales in detail to understand different perspectives and rea= sons to support a combination of opcodes over others.
> > > >
> > > > [1]: https://gr= oups.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/bl= ob/master/bip-0348.md
> > > > [5]: https://gist.githu= b.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
> > > > [6]: https://gist.gi= thub.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> > > > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9= eb608?permalink_comment_id=3D5359072#gistcomment-5359072
> > > > [8]: https://en.bitcoin.it/w/index.php?t= itle=3DCovenants_support&diff=3Dprev&oldid=3D70520
> > > >
> > > > /dev/fd0
> > > > floppy disk guy
> > > >
> > > > --
> > > > 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.com/d/msgid/bitcoindev/38a6f252-afe9-4155= -a341-11a42a9a9007n%40googlegroups.com.
> > >
> > > --
> > > You received this message because you are subscribed to = the Google Groups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails= from it, send an email to bitco= indev+...@googlegroups.com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcu= QktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBW= Xac%3D%40protonmail.com.
> >=20
> > --
> > You received this message because you are subscribed to the G= oogle 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/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mai= l.gmail.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/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com.
------=_Part_1145795_1600931531.1735831001709-- ------=_Part_1145794_2009645589.1735831001709--