From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 02 Jan 2025 05:47:03 -0800 Received: from mail-qv1-f57.google.com ([209.85.219.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tTLXS-0006kt-3n for bitcoindev@gnusha.org; Thu, 02 Jan 2025 05:47:03 -0800 Received: by mail-qv1-f57.google.com with SMTP id 6a1803df08f44-6d88d56beb7sf113033926d6.3 for ; Thu, 02 Jan 2025 05:47:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1735825615; cv=pass; d=google.com; s=arc-20240605; b=Q/pFVzffCRSlQb12QJEBu1GQZRozSaaQqsyYrk++3bI8AP9gLa9oG7IJsX8bQ4tCUu 4BtJ/yWLdDGoTNISF4miOtEa3A9g9a3NSHQLucad7qV92Hl3x4Eej1sMQNoCPriQV+Nq X49Uq5PnPzELWpf+kn2rcuUuFnSXWuWGAaW/upuCFtU/D47wac0cLvfxm3z9uJFymFYm 1oMIGeZ2ulsQh9x0KyJ+X7BFk0iM5Krfgj97TkX5CfTpbKYz6/0N5kYTqcDtcd+NNex+ HDo6bEav3eDxnizwRhc035itZ7GJgS4R5TR5nsjNwQMEnYziSSHmgcu1Gz+CXG3leAi5 OrWA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=; fh=ck+ntOCCaNxBMXvhI6A5briUYihahcC1/dd5SEYFqr4=; b=IeKDcKOMve09xZk8+HfNJ9KYEpKrMG2LTHz5HSYyPl3IZyx5Hc1qC27fj1kekS08R9 zGsTXt+Hgu+WyInZMh6ZtsjFuua39lTCfcpvq+mhM6cDOz52r2k0Bw1QVhtFhr25c+hl E4E5qePo1b3FAojzlR3zGIS/7J08208Pyvl1LBmmhvkXaESXI2kq3z7x4z4gPxTrY+L/ iWU/6WfGyHw+ia8Jv09ZQj9YoBaXoNPUuBIR5yY48Q8HaVwJEjHUIZOrRR1RmZbVSL2r eEorfJCPaEL1G0I5E4/5uXpqMneT7pERFhPHP1O8V/8hagIOcBB2JIpQU8SXX/bGtHhk UeGQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7"; spf=pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735825615; x=1736430415; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=; b=S1zmMU3solEqC7F9BN9C7RTOHtXXupuVontRnhY/Fp/+ktuNwyDzw/ywsTFTRhfJKs Y6/loJJN6cLDBvNk3E6lWR7Ypk+lgXX0sNwu4DzkYQN7Aa7ONua3MlaMrpu/fkPwxGwV PdXzBRscDmJIghXyYriB9VfCIChGSepydadmO57vRz2FhjekGcsxffiufCw6hTQpbc5r beRQo5nXCNYNoo7TZAKMnhOa0TnO6LzGHWAexO8F3K0K2dHHjBZZI38IPxlNUDN5xXIl q+ti10bFeQGD5LniYmnb9LQRQTQf+rU+8bNg4cJ0akmWZlvwjGKwN7n1Cx8MIo+P7v3B WBGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735825615; x=1736430415; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8QdwAy+nEnoza9CH9d+FkIu2LgNBg5Fn5YTHGvbO7mI=; b=H+ilxBQ+NTreEgrQXPwF3PmE5FYwobcgGLOpGwAmvRZSZ/VLRoSepmkU9AVnkAWUMw Qlo1zVWLtv2u2jO4NyVBBqM3Yd+bnrAliiM5j6TCkRt4I0UNDOuFLkZ8ByjJF3hdOohO LZ8/gOvqVG2pxYZLFbBksPJ26C9anATdMuq8ZjdkLML9XxXbg0DN8/STdPs7Gt08KVaZ 9erbgGL8PfELBHvf9DeyrQZGjJDVRN+5jgbt8A26ane5An+bBQcdSBuqBeggewxqkdZy 1IEC43M3Ux58+8fnh3rTa7ehM1XjcYFe24FLQFqGULiMoSolcPCKv6P4Q0coKixW0xjk VOCw== X-Forwarded-Encrypted: i=2; AJvYcCVYiQ0hMTjEbeEEp437rKm00pW18BV3esC9YjBl6CNLsSMUFNM4A3ng1xyVrWoiiSdPWMolaqeTiBnf@gnusha.org X-Gm-Message-State: AOJu0Yy32vUnYD4XfDmhWMHOH2ttlXmQ65c59N8Gw5aFzMDzDi79vLyE /+f7EaFAm/PZAX9sEu6qG/dxA1TnqI79j0sTi5pSyxSa61Lot+6o X-Google-Smtp-Source: AGHT+IHOhbixIIXQ3RVqrqN6iH2HkSjcFL/1eaf76mOE3GnLyc12InEkt6T+EcAzXkeD9Zj5nvhTdg== X-Received: by 2002:a05:6214:486:b0:6d8:b594:c590 with SMTP id 6a1803df08f44-6dd23307cacmr638122976d6.6.1735825615369; Thu, 02 Jan 2025 05:46:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:598b:b0:6d8:f050:cdf8 with SMTP id 6a1803df08f44-6dd15486c4els27058286d6.1.-pod-prod-08-us; Thu, 02 Jan 2025 05:46:52 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXMFE1wAMmeJXYID51EsQfKaebuxjxM/5gOcHjcPUsDh066tNS8ACaW2UFA2kmKhe67kJUqmv8s5NiH@googlegroups.com X-Received: by 2002:a05:620a:4141:b0:7b6:d079:7496 with SMTP id af79cd13be357-7b9ba7e60aamr6309032585a.46.1735825612404; Thu, 02 Jan 2025 05:46:52 -0800 (PST) Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14fms85a; Thu, 2 Jan 2025 05:40:51 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXCT/Xb/NXC25tI2gT0m3+n/bobAtgblAGJG3gVIuU6Szl/ixEkoY5KR3N591tefrs8jmlsxIZq2gvK@googlegroups.com X-Received: by 2002:a05:651c:2209:b0:300:1de5:59e3 with SMTP id 38308e7fff4ca-304685173c8mr126658301fa.2.1735825249453; Thu, 02 Jan 2025 05:40:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1735825249; cv=none; d=google.com; s=arc-20240605; b=BFJGHL5QNt8QOum7n5lsVJAn55Rph22K/UV3hlkjRYRlcswx1vVLNc9eDJuWy2hBsf y42f8CdQ2r/8/lDdO8Gsr0KNvoUhh2yuKp0XEZajwofJtLTN0mXe6oBQ9CExsKkLBMYc vuZCduv6TvEN87CgoYrD1dWoT6JzpqPDLyC1z1Gwb1U8od/DOh6bIg2Uhj7Y2Wxyx1eR VZ4dcH48CGObLcI/DDs7MlrSO8sUB9RVwJiSgrePRr8ZxI1RVPOS+ZSuljvzVkjJOkJY UDPdTZVPrXFowIHHYouwXDwBiU/Lb24hTb2J30f4NNFBplQ0gD4cPONpB8JBkEBk8zxh Lz5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=+28aClvOIL+tnp/AKLXiSKNXWi/1oPzdstXP1jIodT0=; fh=otp8siENmaEy3fGyFfzSjl5yvOyG7SrLkx37VM0SK0s=; b=ZbvV4zoLOiv60WSBpMFU/MA27hLr94Tx8Ykv/x7VNCsElAKHTssE/dJtHJKhy8yNO5 UdhbPvLZY/2Buhg9mWkxVzY5yOQGG+D482eSHwRr9NcBQgm8fEa5XTrjGv/MpsARimNm +kzD5029eKHO4YwAFHxCT0qD9eYNaO4N4nuEUbt04+Of3gtAFB4u//XgfvJ1EKllo5Av vlrHUSwqv33qq70TMYz03qZLEgD2qNbt3kp8l+/BIb09M1inVPr4PmTKKphqNLj3EyKO kG6Et201le7fYECH1Q6V2Y4blbLNd7rmCjDPDiphhLNmmg2ZeZ6dB1YYFh8FZSJE9UYq BrOA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7"; spf=pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch. [79.135.106.101]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3045ae02e91si4464791fa.3.2025.01.02.05.40.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 05:40:49 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) client-ip=79.135.106.101; Date: Thu, 02 Jan 2025 13:40:43 +0000 To: /dev /fd0 From: "'moonsettler' via Bitcoin Development Mailing List" Cc: Ethan Heilman , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki Message-ID: In-Reply-To: References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 60da296a4f50d5f6f9dd8cfdff55e878fa6ab64a MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="zb/UMIv7"; spf=pass (google.com: domain of moonsettler@protonmail.com designates 79.135.106.101 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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: -1.0 (-) Hi Floppy, 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. Main benefit for the network: we can reduce the number of SigOps on-chain w= hich benefits everyone that runs a validating node by making it more econom= ic to use a single signature for multiple elements instead of using somethi= ng 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 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. 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 wrote: > Hi Ethan, > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAI= RCOMMIT is a part of LNHANCE. >=20 > In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN SYM= METRY can be achieved with other opcodes. >=20 > Note: The objections shared in this thread are a summarised version of al= l 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 no = possible before which is interacting with Merkle trees and multi-element co= mmitments in script. PAIRCOMMIT is not significantly more complicated than = CAT, and in a lot of actual use cases CAT was desired for it's more complex= and resource intensive to safely use CAT than PAIRCOMMIT due to witness ma= lleability. > >=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 PAIR= COMMIT. > >=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 enable > > this expressiveness as well. On the other hand, if the Bitcoin > > community does want the expressiveness of CAT, then we should merge > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT and it > > is likely that you can not simulate CAT with PAIRCOMMIT. That said, I > > am not convinced it is impossible that there is no way to simulate CAT > > with PAIRCOMMIT, nor I do feel confident that I know how much less > > powerful PAIRCOMMIT is than CAT. > >=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 arbitrary > > computation by building STARKs with PAIRCOMMIT merkle trees? If not, > > why not? > >=20 > > That said, I have not heard any argument against PAIRCOMMIT from 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 Devel= opment > > Mailing List wrote: > > > > > > Hi All, > > > > > > One thing I would like to make clear before people get the wrong idea= and think this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is = part of LNhance and will be part of the activation client we release soon. = The only way to change that is to demonstrate actual harm. You liking somet= hing else more, is your problem. What you can do about it, is write your ac= tivation client and try to gain consensus on that. There are plenty of vers= ion bits available. Replacing PAIRCOMMIT with CAT would be really easy, but= while CAT is indeed very popular and has a wide support base it is also st= rongly opposed by many who did not choose to participate. I'm not convinced= that this table represents actual developer, let alone ecosystem consensus= . If you decide you want to run an alternative activation effort with CAT i= nstead of PAIRCOMMIT feel free to fork our repo! > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_PARCOMMIT > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > OP_PARCOMMIT seems to be controversial at this moment. > > > > > > I strongly disagree. In my book that's not what controversial means. = Literally nobody managed to come up with a single use case anyone worth not= ing 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 corr= elation between the age of the proposals and their support with the sole ex= ception of APO. > > > > > > > Adds unnecessary complexity > > > > > > That's a subjective value judgement it enables something that was no = possible before which is interacting with Merkle trees and multi-element co= mmitments in script. PAIRCOMMIT is not significantly more complicated than = CAT, and in a lot of actual use cases CAT was desired for it's more complex= and resource intensive to safely use CAT than PAIRCOMMIT due to witness ma= lleability. > > > > > > > Not convinced it is impossible that there is no way to simulate CAT= with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than C= AT. > > > > > > 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 wrote: > > > > > > > Hi Bitcoin Developers, > > > > > > > > I had shared covenants support wiki page link here on [mailing list= ][1] in the last week of November 2024. Multiple changes were made based on= the feedback: > > > > > > > > - Removed 'community support' from 'No'. Rephrased definitions for = 'Prefer' and 'Evaluating'. > > > > - Added LNHANCE category for a combination of opcodes. > > > > - Added links for BIP drafts and a column for 'rationale'. > > > > - Created a separate table for evaluations without a rationale. > > > > > > > > Murch and Gloria shared their feedback in the bitcoin optech [podca= st 333][2]. I have started working on a [page][3] that lists use cases, pro= totype links and primitives used. We can still add more use cases in it. Th= is list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] alo= ne or in combination with other opcodes like [LN SYMMETRY][5]. > > > > > > > > I had verified each entry to avoid spam and fake evaluations. Reard= en was assigned moderator permissions on 8 December 2024 by Theymos to help= me with the moderations. Some edits have been approved by other moderators= . > > > > > > > > Some insights from the table that could help developers working on = different covenant proposals: > > > > > > > > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_AP= O lacks interest among developers, contrary to the belief prior to this exe= rcise. > > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mult= iple covenant proposals. > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not= reviewed by enough developers. OP_PARCOMMIT seems to be controversial at t= his moment. > > > > > > > > Objections: > > > > > > > > ``` > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > SIGHASH_APO > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > LN SYMMETRY is possible with combination of a few opcodes which is = more efficient. Its not the best option for covenants and cannot be used to= improve Ark. Some developers prefer opcodes and not sighash flags. > > > > > > > > Seems to be the result of an attempt to fix signatures to make them= work for a specific use-case, but the end-result is hard-to-reason (for me= ) and not flexible. In general, SIGHASH flags are an encoding of specific p= redicates on the transaction, and I think the Script is better suited to ca= rry the predicate. There is no interesting SIGHASH flag that couldn't be fu= nctionally simulated by introspection + CHECKSIGFROMSTACK (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 doesn't make sens= e because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same = thing. Makes hash caching complex, potentially opening up DoS vectors or qu= adratic sighash. > > > > > > > > Most templates you'd obtain with various combinations of parameters= are meaningless. It implements state-carrying UTXOs in a very dirty way: a= dding additional inputs/outputs with no other meaning than "storing some st= ate". This is ugly, inefficient, and bloats the UTXO set - and it definitel= y will happen if TXHASH is enabled without also enabling a clean way to car= ry state. > > > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune i= t to what people are actually using covenants for, instead of prematurely o= ptimizing 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 c= ases (DEX, AMM and Hashrate Escrow). Enables granular transaction introspec= tion through abuse of schnorr signatures and OP_CHECKSIG. Can be used for i= nteresting use cases but alone does it poorly and inefficiently. > > > > > > > > People can and will litter the chain with inefficient/ugly Scripts = if activated alone. Since it happens to enable generic introspection by acc= ident, and therefore an ugly version of state-carrying UTXOs, it shouldn't = be enabled without more ergonomic opcodes for those use cases. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > OP_INTERNALKEY > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > There are 3 'No' in the table, I couldn't find anything relevant in= the rationales. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > OP_PAIRCOMMIT > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Adds unnecessary complexity, redundant if OP_CAT is activated in fu= ture and added for specific use case. LN SYMMETRY is possible without this = opcode. It does not compose with anything that involves transaction introsp= ection due to its specified tagged hash. Some developers prefer OP_CAT. > > > > > > > > Not convinced it is impossible that there is no way to simulate CAT= with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than C= AT. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > OP_CHECKTEMPLATEVERIFY > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Limited in scope and not recursive. > > > > ``` > > > > > > > > I have tried my best to remain unbiased in writing this summary and= approving edits. There are a few things that I want to share and it could = be a result of the aggressive marketing: > > > > > > > > - A spammer had edited the table to remove all evaluations except i= n 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 e= valuations exist in the table. > > > > - I [requested][7] Udev (CatSwap) to add details about evaluation o= f other opcodes and SIGHASH_APO. > > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incor= rect signet stats and seems to be rephrased version of another rationale. E= valuation had 'weak' for OP_CTV before adding the rationale. > > > > - An edit with duplicate rationale (in support of OP_CAT) was rejec= ted because sharing the link for a rationale submitted by other developer a= dds no value in the table. > > > > > > > > Evaluations without a rationale have some 'No' in different cells. = Although none of them are backed by a rationale so cannot be considered 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 achieve tech= nical 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 evaluatio= ns in the table and everyone who shared updates on twitter. It was a coordi= nated effort to reach some technical consensus. You can read all the ration= ales in detail to understand different perspectives and reasons to support = a combination of opcodes over others. > > > > > > > > [1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2= IAQAJ > > > > [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/4a14614fa850511d63a5b2a9b5104cb= 7 > > > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56d= d9 > > > > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb= 608?permalink_comment_id=3D5359072#gistcomment-5359072 > > > > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_support&di= ff=3Dprev&oldid=3D70520 > > > > > > > > /dev/fd0 > > > > floppy disk guy > > > > > > > > -- > > > > You received this message because you are subscribed to the Google = Groups "Bitcoin Development Mailing List" group. > > > > To unsubscribe from this group and stop receiving emails from it, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com. > > > > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-Q= zfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send = an email to bitcoindev+unsubscribe@googlegroups.com. > > To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-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/= BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd2= 7VQfODaemn-jksB8bLFGoM8a70f3xjWI%3D%40protonmail.com.