From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 03 Jan 2025 04:15:37 -0800 Received: from mail-qk1-f186.google.com ([209.85.222.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tTgaW-0003Re-FL for bitcoindev@gnusha.org; Fri, 03 Jan 2025 04:15:37 -0800 Received: by mail-qk1-f186.google.com with SMTP id af79cd13be357-7b6e7f07332sf121024885a.1 for ; Fri, 03 Jan 2025 04:15:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1735906530; cv=pass; d=google.com; s=arc-20240605; b=dg6EQiJg8LMUG89I/Hd7QGzfEWcZ/i02hhAIDAtLgWDlS17K5VZvmwkj9Z0ndO7JrM tgftRdcuOe/jqssPIOZXAaLSFYVZZJRw/FOV9NQUzj6YmAh8Is56k3t2ICBXBbboZHLx kRRNmj1bvwXNJfv8KdkSAbWFWvQOlTDohztdfBIpK8FmruN7goQg00ulI91Y9zOA0FaQ 0G312BICqWTIjTZw7oB60mkbJIZwWye7rBzBdzIq4zOq05vn2KQlWcEz9Lp965SxkTKz 5mCNXsuKbVEXwQdxlNPwIIwe0PV5MXK1/lNiCkbFgCgDXkdfCOUZaoXBsv9jfLlAlc01 x6zg== 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=RjcIdfczDWoz64nwLhurIhDwFmqtdx4hXSoUlbXQHUo=; fh=eX/FUEdg6mds3gVr4CQk/gLxoQr/nW05SkGRSosQa3E=; b=Rqwvv7yJxzNzo/NNynnA+gXLXsWx9QycMHis6vDMWiLDm8TMQbpyKRKTMBAsSs/HyE CXR270OM2cDTx84TKAMmsDjVS4IvPmS0JZziILg7lEJ329bXdu2Es0Zl9fSH6frtvBZO AN39WGCQZCLsnDqD6H2n+InsRieESn5WvVZHvjBHHzp90l3p7pk/v1f77dpdSZC2yaIi h5WajpiSamRg6iqhm4IKKrFc5qZFERMAeTxmBZegqCDpZXyQ9/lUzFf18DwZ7IjAjyUb PKepxJ38FicW1LGrWRuGMzcQoV0S79NsTkA0UaFy5eVu32ac5vfxAXp+Q4q0gv+VxG11 PSFA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=DTXDtwWd; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.135 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=1735906530; x=1736511330; 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=RjcIdfczDWoz64nwLhurIhDwFmqtdx4hXSoUlbXQHUo=; b=DTsXWEVs0t4LvqxTQ/uHrKhbk6zReAqQTSRGYNQZLW+PVldmO78hVXsxk1IpWeCHzi 2g3RySik+LEEzTwioqzeVpw2YYEGHt2IO5ESODKMC0qYtDCbpLsemv4ERiWHKxvMPHdR jPY43x/xBnOzTK05T1anMCW+kW3RY4TRJ18cw5zUez+LXDLgd81pudfC3HmxxdRdLNCv NiAwN6i/IGR9j6TjU8B9y3qefOy3fAtzxVQVQ2XcwrEIT4WDp1NYjxzBhvH3q8B8UEsy FCuKHQ6v4ssGxNBactbXsU32YLnj/QBJqIDTuFuAhvWFe99qb2Vq4Y7xJJwo62kS03bi a8sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735906530; x=1736511330; 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=RjcIdfczDWoz64nwLhurIhDwFmqtdx4hXSoUlbXQHUo=; b=oTAOu1q82zkyT2pDdcjMuqJjvdlHbjM5xily9e9gRbdy8jr/0jZW+XkUnlagYzQLOz ihC1k0YJ4yir5uF2g5det1tBw6zKwNeWVULajAsR14Kt1KJuXYnedrwxMDcH42OGXhd2 fxFrZ7YjE0Fxn+dwdRi6AxNvBk5wGbKjHPsjzMZ1OoWOoLSv41waAjfLpbpoUyD7wKcF 1BSH5WUdkZTAD317Nb3PxMpCWlTkRryno+fyGqVuMMSoUYJmT4VWfxf0Vkw5xnJbYpKw dota7Hxo4jRWmoRx0LUM+vZzbeUgux9kubPLWkaZQh5K+MG+awDNENA8tyLHOWDp5Wsb pcjA== X-Forwarded-Encrypted: i=2; AJvYcCVquQHr5r0UB0FI5XLaOcAIah93PQkIA3o4Wfee4sdlp57eMb8t8JS7ejNPQyVpW+HdRHgNYF/8qvvE@gnusha.org X-Gm-Message-State: AOJu0Yy9QP1NnElYtCy+BWboy9uuJhB9KO7Lc38EdhLmy4pIo4J7ERnX dWRzIdjmtFHf1Jpo9hvavxwjxd3Gzgud374R47V16C64RRtJ1EhO X-Google-Smtp-Source: AGHT+IEs9MaY2rpPeTakWmiutRfEoSboDPoOd3Jyb9seWrKQtDINAahJWlWi1SRew+7/ksSZ7J6QrQ== X-Received: by 2002:a05:620a:4089:b0:7b7:142d:53c4 with SMTP id af79cd13be357-7b9ba81273bmr6910398285a.54.1735906529733; Fri, 03 Jan 2025 04:15:29 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:584a:0:b0:468:f965:33af with SMTP id d75a77b69052e-46a3b048825ls25440641cf.0.-pod-prod-02-us; Fri, 03 Jan 2025 04:15:27 -0800 (PST) X-Received: by 2002:a05:620a:2913:b0:7b6:d6e5:ac62 with SMTP id af79cd13be357-7b9ba6fd878mr6698778585a.6.1735906527495; Fri, 03 Jan 2025 04:15:27 -0800 (PST) Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14fms85a; Fri, 3 Jan 2025 03:59:57 -0800 (PST) X-Received: by 2002:a05:600c:5254:b0:436:18e5:6917 with SMTP id 5b1f17b1804b1-4366790f200mr470433435e9.0.1735905595498; Fri, 03 Jan 2025 03:59:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1735905595; cv=none; d=google.com; s=arc-20240605; b=jZ6mkjgATj2yCmjryuNugvdZd0/5fQXqwC8G4/9udT3Xt0Pddl+ZOOnEpXpy9Kz8MJ Yim7n0xmmAjQ1wsKt+L1jeAW35+smYwaRzGoIS958XkqDZEII36F03Ca+GlnMUui4qyX LmiyeDDcGXnWTlUAcWgCqNLVmqIdfWVdhEs78Hw5sUDHh6xbZ1xXIIlhEohVGSo13cA4 rXElf0mFkT9/ZMIZxpJfPd+gAr3kRq6ms16c5O+bpjpdL8ObeXVt//xt/J1E0zW/oFDZ /OsL33wBIH0bDdV/U/fR+uYMNUFhZc9w5yeXayj/hGBQvXxsPNhko265f2ubAbXjwrUQ dXCw== 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=p/eM+7UsaQT7gYbSMMhCUoSfvRxv5I8d69PjfGsvjs4=; fh=+67N2uHR2MfeB757DuDnNuhtYMQ1l3OX1mrsWyqvKgo=; b=kOi9cYilxyjl3xbfsMtAFEJJTvO6i1CUyiKRti7zedSBJ59waXTkDNOwAg5DS7/V3z frDfydu+FGXdFyK3ijht9pJP/T4p2V9wTBN814xDJhjvDK4P9XmNqkz1VY9xGrsZ2JLe dLI9tvF4ujSU/vMQqy1bwXBqiEfkSC2VFQslJlMY4+8g0R8r5m3vWeBwMCsA34jTft4d YTCXSnOVt0KAKajuKv/yYgVruKkK2IH8Z52i3Z0B0UlN2+3Kks8qoLRoAYwc7Gz04vRV M2mrugr0DhkGzuHpTtMIdoY0mpQLpyxLVwQC2X+GAchoeVP3ZI0eJA8w24VdC0BDA9C0 W0QA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=DTXDtwWd; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.135 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch. [185.70.40.135]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-436633b9f5dsi12374685e9.1.2025.01.03.03.59.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 03:59:55 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.135 as permitted sender) client-ip=185.70.40.135; Date: Fri, 03 Jan 2025 11:59:50 +0000 To: /dev /fd0 From: "'moonsettler' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki Message-ID: <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com> In-Reply-To: References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 913199941455aacd33de9a81d3eccdb98ce42f54 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=DTXDtwWd; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.135 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, Of course I appreciate thoughtful evaluations. But my point stands, I encourage everyone to look at this table as means to= engage in discussion not some indicator of "consensus" by any means. And I emphasized this, because there was a weird perception emerging, and e= ven 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 wrote: > Hi moonsettler, > > 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, etc. >=20 > 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. >=20 > > Calling it "unnecessary complexity" is not a valid technical observatio= n in any shape or form. It would provide optimization for many contracts an= d use cases even if we had CAT. I explained this to you in private first, y= et you keep insisting on this completely invalid objection. >=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 just me w= ho finds this opcode irrelevant. Please respect the developers who shared t= heir evaluations in the table even if you disagree with them. If you cannot= appreciate efforts to review proposals and reach technical consensus, at l= east avoid calling reviews/evaluations as "voting". >=20 > "Unnecessary" because LN symmetry (efficient) is possible without it. "Co= mplexity" is introduced because it will be used for everything possible wit= h it in bitcoin script and not just the use cases described in your email. >=20 > /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 w= rote: >=20 > > Hi Floppy, > >=20 > > 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. > >=20 > > 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. > >=20 > > Calling it "unnecessary complexity" is not a valid technical observatio= n in any shape or form. It would provide optimization for many contracts an= d use cases even if we had CAT. I explained this to you in private first, y= et you keep insisting on this completely invalid objection. > >=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 wrote: > >=20 > > > Hi Ethan, > > > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP= _PAIRCOMMIT is a part of LNHANCE. > > > > > > In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN= SYMMETRY can be achieved with other opcodes. > > > > > > Note: The objections shared in this thread are a summarised version o= f all the rationales and not my person opinion. > > > > > > /dev/fd0 > > > floppy disk guy > > > > > > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman wrote: > > > > > > > One of the CAT authors here > > > > > > > > > > [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-elemen= t commitments in script. PAIRCOMMIT is not significantly more complicated t= han CAT, and in a lot of actual use cases CAT was desired for it's more com= plex and resource intensive to safely use CAT than PAIRCOMMIT due to witnes= s malleability. > > > > > > > > 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. > > > > > > > > My primary concern is not PAIRCOMMIT itself, but the rationale for = PAIRCOMMIT. > > > > > > > > The rationale for PAIRCOMMIT rests on the assumption that the Bitco= in > > > > community does not want the expressiveness of CAT. If we assume thi= s > > > > is the case, then we should be very careful PAIRCOMMIT does not ena= ble > > > > 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. > > > > > > > > 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 arbitr= ary > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If not= , > > > > why not? > > > > > > > > That said, I have not heard any argument against PAIRCOMMIT from th= ose > > > > 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 D= evelopment > > > > 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 so= on. The only way to change that is to demonstrate actual harm. You liking s= omething else more, is your problem. What you can do about it, is write you= r activation client and try to gain consensus on that. There are plenty of = version 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 als= o strongly opposed by many who did not choose to participate. I'm not convi= nced that this table represents actual developer, let alone ecosystem conse= nsus. If you decide you want to run an alternative activation effort with C= AT 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 mea= ns. 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 th= ose that prefer CAT as plain trolling. This BIP is young, there is a clear = correlation between the age of the proposals and their support with the sol= e exception 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-elemen= t commitments in script. PAIRCOMMIT is not significantly more complicated t= han CAT, and in a lot of actual use cases CAT was desired for it's more com= plex and resource intensive to safely use CAT than PAIRCOMMIT due to witnes= s malleability. > > > > > > > > > > > Not convinced it is impossible that there is no way to simulate= CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is th= an 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 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 base= d 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 [p= odcast 333][2]. I have started working on a [page][3] that lists 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_CHECKSIGFROMSTACK][4]= alone or in combination with other opcodes like [LN SYMMETRY][5]. > > > > > > > > > > > > I had verified each entry to avoid spam and fake evaluations. R= earden was assigned moderator permissions on 8 December 2024 by Theymos to = help me with the moderations. Some edits have been approved by other modera= tors. > > > > > > > > > > > > Some insights from the table that could help developers working= on different covenant proposals: > > > > > > > > > > > > 1. Multiple ways to achieve LN symmetry were discovered. SIGHAS= H_APO lacks interest among developers, contrary to the belief prior to this= exercise. > > > > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of = multiple covenant proposals. > > > > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are= not reviewed by enough developers. OP_PARCOMMIT seems 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 covenants and cannot be use= d 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 (fo= r me) and not flexible. In general, SIGHASH flags are an encoding of specif= ic predicates on the transaction, and I think the Script is better suited t= o carry the predicate. There is no interesting SIGHASH flag that couldn't b= e functionally simulated by introspection + CHECKSIGFROMSTACK (or other Scr= ipt-based approaches), and that seems to me a much cleaner and ergonomic wa= y 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 undesir= able use cases. Unaddressed comments in the BIP and the delay doesn't make = sense because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the s= ame thing. Makes hash caching complex, potentially opening up DoS vectors o= r quadratic sighash. > > > > > > > > > > > > Most templates you'd obtain with various combinations of parame= ters are meaningless. It implements state-carrying UTXOs in a very dirty wa= y: adding additional inputs/outputs with no other meaning than "storing som= e state". This is ugly, inefficient, and bloats the UTXO set - and it defin= itely will happen if TXHASH is enabled without also enabling a clean way to= carry state. > > > > > > > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tu= ne it to what people are actually using covenants for, instead of premature= ly 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 u= se cases (DEX, AMM and Hashrate Escrow). Enables granular transaction intro= spection through abuse of schnorr signatures and OP_CHECKSIG. Can be used f= or interesting use cases but alone does it poorly and inefficiently. > > > > > > > > > > > > People can and will litter the chain with inefficient/ugly Scri= pts if activated alone. Since it happens to enable generic introspection by= accident, and therefore an ugly version of state-carrying UTXOs, it should= n'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 relevan= t 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 i= n future and added for specific use case. LN SYMMETRY is possible without t= his opcode. It does not compose with anything that involves transaction int= rospection 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 th= an 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 share and it co= uld be a result of the aggressive marketing: > > > > > > > > > > > > - A spammer had edited the table to remove all evaluations exce= pt in favor of OP_CAT and it was rejected. > > > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention anyth= ing about other opcodes and SIGHASH_APO. It is only focused on OP_CAT howev= er evaluations exist in the table. > > > > > > - I [requested][7] Udev (CatSwap) to add details about evaluati= on of other opcodes and SIGHASH_APO. > > > > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with i= ncorrect signet stats and seems to be rephrased version of another rational= e. Evaluation had 'weak' for OP_CTV before adding the rationale. > > > > > > - An edit with duplicate rationale (in support of OP_CAT) was r= ejected because sharing the link for a rationale submitted by other develop= er adds no value in the table. > > > > > > > > > > > > Evaluations without a rationale have some 'No' in different cel= ls. 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 = 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 evalu= ations in the table and everyone who shared updates on twitter. It was a co= ordinated effort to reach some technical consensus. You can read all the ra= tionales in detail to understand different perspectives and reasons to supp= ort a combination of opcodes over others. > > > > > > > > > > > > [1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeE= uls2IAQAJ > > > > > > [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/4a14614fa850511d63a5b2a9b51= 04cb7 > > > > > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26b= c56dd9 > > > > > > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428e= f9eb608?permalink_comment_id=3D5359072#gistcomment-5359072 > > > > > > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_suppor= t&diff=3Dprev&oldid=3D70520 > > > > > > > > > > > > /dev/fd0 > > > > > > floppy disk guy > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Goo= gle Groups "Bitcoin Development Mailing List" group. > > > > > > To unsubscribe from this group and stop receiving emails from i= t, 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 Googl= e 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/b= itcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzI= H0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.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, s= end an email to bitcoindev+...@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gm= ail.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+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/c411dee9-1937-42fd-bc66-d347ddbff506n%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/= 6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxT= ZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk%3D%40protonmail.com.