From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 16 Jan 2025 05:21:48 -0800 Received: from mail-qv1-f55.google.com ([209.85.219.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tYPog-0000cn-Ef for bitcoindev@gnusha.org; Thu, 16 Jan 2025 05:21:48 -0800 Received: by mail-qv1-f55.google.com with SMTP id 6a1803df08f44-6dfa69e6983sf15491916d6.1 for ; Thu, 16 Jan 2025 05:21:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1737033700; cv=pass; d=google.com; s=arc-20240605; b=aFQCtfuvJzN9SCFGkGhGzFGnh3CX6x9iX++zZcYmsM2og6KnZjchJtzcKz/PVjO6// W+B37Iv1cJJyq7SlihKt/ZBGyjmSynDV87ShlymOut8CRVct5hGl1GUEw7w3zD7C16X8 /xFW02uUHSiZFOemMb5iVajY5GQNeEJjbCPy43NQUkmafpZHkqNnPziIHumsdzxiDJ/1 O+r9gzZBlxN0oCMjS09aWTSK+LRbKA6a5LDAZxddE7VLv8OJERysFg76U8KqaYxy59C/ R+NC1scUjwCjhZDWYiCBz2fiVI0gouqgz7d73QsOR/xyroocvx9VkqHKUyQi3avZi0XF 6JXA== 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=1lt862cZi01w91MY4NLrfWZGrbqYScgHUlHVuC9f3MA=; fh=e68v/eeU1P2IsR6iXs4KAm9cS9uonkg25o0+Sn3nbWM=; b=OKPmPwmJbJsRH+GdDLHpZFvAPc/oE49d2DLJh1KAF5zeGlRlYeTQz/JW9LvPGEwtuB WC0geocRkfX5tKbqFwZhyOENay4M0f6IHIrJI3dX37rUTbe+YmP9VZqfC432ZQZPvDHx +zkMRNPMAewI3tlwtnpsmbi6smU+/udJjtQbHTcRF4E96aQAiVa3eafwjPwpe1HpB5XQ dP6oxBoMeUneBZwpCdtdZpcFxuERNoj4h/9nO0Eq4fNrvL7YnQi1RmknOXACEB0QYDgV w+3FVU0A5C8EPCFUQOGE4+SE5Q5ttGv3FdDWUdmwJM1bfoP95n+03pYUJ0hMpcZj/qf4 QfpQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=jPAtz8JG; 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=1737033700; x=1737638500; 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=1lt862cZi01w91MY4NLrfWZGrbqYScgHUlHVuC9f3MA=; b=w01qFB/xcbgUigY2rngF+AtndGPQnVyDgyQsxB/vrSJxc9KK1W47+ql5oMfaFognaB tWc4I9qrkW3zcI8cLMgG99b49MmUfEykOZqImOOYUJiSMqhFD+W9lP1pXF9zm/i9hqal bNCxmQau38JY4wGr9ytj9lNdpFCaAw27psXtSJMR7xTRH65Jir0ol/odjYzYOkUXSbI4 S/ResbQkR05lIQp2Bz6COeX530c6D2OBOLJehAi5on4jrnLgDqaaECMT2T9mxCI9sUB4 DZfeyeAFqPPmYpSy95bAdsuZESf16I+CnodUuNhLbvvihC6tAOfMc28KJ8h4MsnMF8Qp +e7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737033700; x=1737638500; 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=1lt862cZi01w91MY4NLrfWZGrbqYScgHUlHVuC9f3MA=; b=dPZcBM0H26+qAfOJDSd4iRDvFtbpfPrBKBTksB9ls81R/Tx/jyUwZiOvy4a787olfv EHmH9MFlI+lUXr4DD3uPKWErJWVejwSUR0Z7U0SS2MxBgir1loqS6YjvPhue/IYLo06v J0yWVrIYvW5+MRU/n3766eJLkkUkUqI7nPRGuZyc8E2qK6ytyQVmnbKQH9NCPGMVAfhB Bib4QS8swkW3Y9ZwRo7OE2Zml4bUO9KRXWDH7EtvL0Stv9x6qc6pB6xUupMQ88vGszbQ 3VKsoE2GgSihiS+fomXhWY+C4FlCb9VCpIOnnFtoD1203lEHm4ySZChRJcxcuW4oLtHp szIQ== X-Forwarded-Encrypted: i=2; AJvYcCV7bveGpK0ZCGfqJzhdPJTWQh+6q6jHsyiwPdPCBd4ieRVIxJuj6zDJIX6HIKnjJMfc0j21m3ZkPcGe@gnusha.org X-Gm-Message-State: AOJu0YwrwL7Zmd0e6yAg/K3V6DyGqkriTt824juh5Qk5xRqBo9YWM2rg f36MtBjpNRnjdqL7NWpcjqSyz6q8rEY5g+ANeqVm8Wybo/f/Lkr9 X-Google-Smtp-Source: AGHT+IF4WhtB+r3ujyNFUIBwZDglEVsUFfRlaG8lyWwtKmjOkmoIXoPQVzwDrUWKuXTiLXgIxckGAw== X-Received: by 2002:a05:6214:2267:b0:6d8:f612:e27d with SMTP id 6a1803df08f44-6df9b2dd8a6mr411960066d6.32.1737033699683; Thu, 16 Jan 2025 05:21:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:622a:1445:b0:467:5082:dafc with SMTP id d75a77b69052e-46e02e86938ls19832221cf.2.-pod-prod-02-us; Thu, 16 Jan 2025 05:21:36 -0800 (PST) X-Received: by 2002:a05:620a:4052:b0:7b6:d1e1:a22e with SMTP id af79cd13be357-7bcd9715c0dmr4892816585a.29.1737033696048; Thu, 16 Jan 2025 05:21:36 -0800 (PST) Received: by 2002:a05:620a:8503:b0:7b6:dcc4:6708 with SMTP id af79cd13be357-7be5b6a046ems85a; Thu, 16 Jan 2025 04:32:24 -0800 (PST) X-Received: by 2002:a5d:47c9:0:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-38a872fbcefmr23804190f8f.4.1737030742286; Thu, 16 Jan 2025 04:32:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1737030742; cv=none; d=google.com; s=arc-20240605; b=FkQLHdro+ytwMf4BcTtofiqZGnmOhRK3rNkTLzL2J9o8U8bkOGYy8GCR9AD2ZAh/H9 Wjpb8E4/C0bsgJ/YJKCDEixtnQydMUSFgKoOwQshEUEia6P6/kYIV3eE/3XNlUZPKpfI c6wUKrp6YhPkldhKVn5W/c4P7CO3wDtZIf9MkfR62yonLRuMJ8weeIFeAll17V5ZL79h zyb5ZRN3pFSVnJzZm/fkzVHoHW0LArfHJuv7+i5dUEVi2UsrmL1GRf/gGe8g+iep4ASB ynoGfT5mFfWecseg7izTwyqZcKDti8lWBDTDesve8Dlkkroh1HnEWslcANv2gfjyGCPO C3NQ== 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=v6cH7nFVYbtSpDCEBGdmplQfTG111da7h7mUe3bDrEM=; fh=+67N2uHR2MfeB757DuDnNuhtYMQ1l3OX1mrsWyqvKgo=; b=G5FV/kYlVBTSzgT2LSGQIMHHQ+psl0weqjyeC3pcCmSFgW1Yc7EfK/WQp8DmMsi3CP URKImTg7ywJk6DXgdivYWirKlF19CyXZQ/HjGrqmz5k7zFbmo+rulB4JE+JJIOyiekYQ lW1TIZ1AF16fAHTC+9aaSQZfHsWz1EBoTigqIndLu5+6NcyhKcddFYO4cayMrgwhNAWq 3lg61hhJ2MZGHe4+WnorF4PhN7ZbfGS2S+R7tbT7qWD2A9sX6zAfxLMicO77LobohaJv xLKFJiYssEO8j4Ly6MahdN/1Prjb9qJ6glyPD+7pAvhnc9XCTTxBuAwpF5k0/rUqies+ LlKQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=jPAtz8JG; 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-437c0f0317dsi2621535e9.0.2025.01.16.04.32.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 04:32:22 -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: Thu, 16 Jan 2025 12:32:18 +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: In-Reply-To: <3f12a08f-f303-459a-b50d-36e775372bd3n@googlegroups.com> References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com> <3f12a08f-f303-459a-b50d-36e775372bd3n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: b330b91df012125374d6b1096d60a5980d100248 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=jPAtz8JG; 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, As I mentioned before, I believe it's a mistake to structure the table this= way. People should express preference to actual proposals up for activation! Right now there are only 3: CovTools by jamesob LNhance by reardencode C3PO by well... I guess me Altho I'm not aware of an activation client effort for CovTools, but it was= PR-ed to core. Probably too late for this now, enjoy the Covenant Beauty Contest! BR, moonsettler On Wednesday, January 15th, 2025 at 9:09 PM, /dev /fd0 wrote: > Hi moonsettler, > Maybe you missed this part in the original post: >=20 > > Evaluations without a rationale have some 'No' in different cells. Alth= ough none of them are backed by a rationale so cannot be considered for con= sensus discussion. The table is still updated regularly so you may see some= of them with a rationale in 2025. Any suggestions to help achieve technica= l consensus are most welcome. >=20 > > What's next? >=20 > > - More rationales in the table > > - Discuss objections on mailing list (if any) >=20 > Let me know if you know a better way to reach "consensus". This mailing l= ist post was intended to discuss everything because I am done with consensu= s on twitter. >=20 > /dev/fd0 > floppy disk guy > On Friday, January 3, 2025 at 5:45:29=E2=80=AFPM UTC+5:30 moonsettler wro= te: >=20 > > Hi FLoppy, > >=20 > > Of course I appreciate thoughtful evaluations. > >=20 > > But my point stands, I encourage everyone to look at this table as mean= s to engage in discussion not some indicator of "consensus" by any means. > >=20 > > And I emphasized this, because there was a weird perception emerging, a= nd even your own summary had this feel to it. > >=20 > > BR, > > moonsettler > >=20 > >=20 > > Sent with Proton Mail secure email. > >=20 > > On Thursday, January 2nd, 2025 at 4:16 PM, /dev /fd0 wrote: > >=20 > > > Hi moonsettler, > > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance doe= s. 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 [rational= e][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY. > > > > > > > Calling it "unnecessary complexity" is not a valid technical observ= ation in any shape or form. It would provide optimization for many contract= s and use cases even if we had CAT. I explained this to you in private firs= t, yet you keep insisting on this completely invalid objection. > > > > > > It is a valid objection and I find it disappointing that you think pe= ople will change their opinion about an opcode if you build [activation cli= ent][2] or a different table. If you read all the rationales, its not just = me who finds this opcode irrelevant. Please respect the developers who shar= ed their evaluations in the table even if you disagree with them. If you ca= nnot appreciate efforts to review proposals and reach technical consensus, = at least avoid calling reviews/evaluations as "voting". > > > > > > "Unnecessary" because LN symmetry (efficient) is possible without it.= "Complexity" is introduced because it will be used for everything possible= with it in bitcoin script and not just the use cases described in your ema= il. > > > > > > /dev/fd0 > > > floppy disk guy > > > > > > [1]: https://gitlab.com/-/snippets/4777553 > > > [2]: https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/eodYc71lD= AAJ > > > On Thursday, January 2, 2025 at 7:16:55=E2=80=AFPM UTC+5:30 moonsettl= er wrote: > > > > > > > Hi Floppy, > > > > > > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance doe= s. 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 which benefits everyone that runs a validating node by making it mor= e economic to use a single signature for multiple elements instead of using= something like the ReKey technique. > > > > > > > > Calling it "unnecessary complexity" is not a valid technical observ= ation in any shape or form. It would provide optimization for many contract= s and use cases even if we had CAT. I explained this to you in private firs= t, 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 wrote: > > > > > > > > > Hi Ethan, > > > > > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Wherea= s OP_PAIRCOMMIT is a part of LNHANCE. > > > > > > > > > > In this context, OP_PAIRCOMMIT adds unnecessary complexity becaus= e LN SYMMETRY can be achieved with other opcodes. > > > > > > > > > > Note: The objections shared in this thread are a summarised versi= on of all the rationales and not my person opinion. > > > > > > > > > > /dev/fd0 > > > > > floppy disk guy > > > > > > > > > > On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman wr= ote: > > > > > > > > > > > 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-el= ement commitments in script. PAIRCOMMIT is not significantly more complicat= ed 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 wi= tness 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 B= itcoin > > > > > > 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 m= erge > > > > > > CAT. PAIRCOMMIT is well designed to be less expressive than CAT= and it > > > > > > is likely that you can not simulate CAT with PAIRCOMMIT. That s= aid, I > > > > > > am not convinced it is impossible that there is no way to simul= ate CAT > > > > > > with PAIRCOMMIT, nor I do feel confident that I know how much l= ess > > > > > > 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 rea= lly > > > > > > understand the limits of PAIRCOMMIT. For instance can you do ar= bitrary > > > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If= not, > > > > > > why not? > > > > > > > > > > > > That said, I have not heard any argument against PAIRCOMMIT fro= m those > > > > > > against CAT, so perhaps they are comfortable with it. > > > > > > > > > > > > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT. > > > > > > > > > > > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitco= in Development > > > > > > Mailing List wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > One thing I would like to make clear before people get the wr= ong idea and think this is some form of voting, OP_INTERNALKEY and OP_PARCO= MMIT is part of LNhance and will be part of the activation client we releas= e soon. The only way to change that is to demonstrate actual harm. You liki= ng 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 plenty= of version bits available. Replacing PAIRCOMMIT with CAT would be really e= asy, 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'm not c= onvinced that this table represents actual developer, let alone ecosystem c= onsensus. If you decide you want to run an alternative activation effort wi= th CAT instead of PAIRCOMMIT feel free to fork our repo! > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > OP_PARCOMMIT > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > > > > > > > > > OP_PARCOMMIT seems to be controversial at this moment. > > > > > > > > > > > > > > I strongly disagree. In my book that's not what controversial= means. Literally nobody managed to come up with a single use case anyone w= orth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" fro= m those that prefer CAT as plain trolling. This BIP is young, there is a cl= ear correlation between the age of the proposals and their support with the= sole exception of APO. > > > > > > > > > > > > > > > Adds unnecessary complexity > > > > > > > > > > > > > > That's a subjective value judgement it enables something that= was no possible before which is interacting with Merkle trees and multi-el= ement commitments in script. PAIRCOMMIT is not significantly more complicat= ed 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 wi= tness malleability. > > > > > > > > > > > > > > > Not convinced it is impossible that there is no way to simu= late CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT i= s 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 wrote: > > > > > > > > > > > > > > > Hi Bitcoin Developers, > > > > > > > > > > > > > > > > I had shared covenants support wiki page link here on [mail= ing list][1] in the last week of November 2024. Multiple changes were made = based on the feedback: > > > > > > > > > > > > > > > > - Removed 'community support' from 'No'. Rephrased definiti= ons 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 ration= ale. > > > > > > > > > > > > > > > > Murch and Gloria shared their feedback in the bitcoin optec= h [podcast 333][2]. I have started working on a [page][3] that lists use ca= ses, prototype links and primitives used. We can still add more use cases i= n 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 evaluation= s. Rearden was assigned moderator permissions on 8 December 2024 by Theymos= to help me with the moderations. Some edits have been approved by other mo= derators. > > > > > > > > > > > > > > > > Some insights from the table that could help developers wor= king on different covenant proposals: > > > > > > > > > > > > > > > > 1. Multiple ways to achieve LN symmetry were discovered. SI= GHASH_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 controvers= ial 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 w= hich 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 m= ake 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 sp= ecific predicates on the transaction, and I think the Script is better suit= ed to carry the predicate. There is no interesting SIGHASH flag that couldn= 't be functionally simulated by introspection + CHECKSIGFROMSTACK (or other= Script-based approaches), and that seems to me a much cleaner and ergonomi= c 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 und= esirable use cases. Unaddressed comments in the BIP and the delay doesn't m= ake sense because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve t= he same thing. Makes hash caching complex, potentially opening up DoS vecto= rs or quadratic sighash. > > > > > > > > > > > > > > > > Most templates you'd obtain with various combinations of pa= rameters are meaningless. It implements state-carrying UTXOs in a very dirt= y way: adding additional inputs/outputs with no other meaning than "storing= some state". This is ugly, inefficient, and bloats the UTXO set - and it d= efinitely will happen if TXHASH is enabled without also enabling a clean wa= y to carry state. > > > > > > > > > > > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fin= e tune it to what people are actually using covenants for, instead of prema= turely 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 undesirab= le use cases (DEX, AMM and Hashrate Escrow). Enables granular transaction i= ntrospection through abuse of schnorr signatures and OP_CHECKSIG. Can be us= ed for interesting use cases but alone does it poorly and inefficiently. > > > > > > > > > > > > > > > > People can and will litter the chain with inefficient/ugly = Scripts if activated alone. Since it happens to enable generic introspectio= n by accident, and therefore an ugly version of state-carrying UTXOs, it sh= ouldn'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 rel= evant 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 activat= ed in future and added for specific use case. LN SYMMETRY is possible witho= ut this opcode. It does not compose with anything that involves transaction= introspection due to its specified tagged hash. Some developers prefer OP_= CAT. > > > > > > > > > > > > > > > > Not convinced it is impossible that there is no way to simu= late CAT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT i= s 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 sum= mary and approving edits. There are a few things that I want to share and i= t could be a result of the aggressive marketing: > > > > > > > > > > > > > > > > - A spammer had edited the table to remove all evaluations = except in favor of OP_CAT and it was rejected. > > > > > > > > - [Rationale][6] added by Aaron (sCrypt) does not mention a= nything about other opcodes and SIGHASH_APO. It is only focused on OP_CAT h= owever evaluations exist in the table. > > > > > > > > - I [requested][7] Udev (CatSwap) to add details about eval= uation of other opcodes and SIGHASH_APO. > > > > > > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale wi= th incorrect signet stats and seems to be rephrased version of another rati= onale. Evaluation had 'weak' for OP_CTV before adding the rationale. > > > > > > > > - An edit with duplicate rationale (in support of OP_CAT) w= as rejected because sharing the link for a rationale submitted by other dev= eloper adds 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 consid= ered 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 achi= eve 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 e= valuations in the table and everyone who shared updates on twitter. It was = a coordinated effort to reach some technical consensus. You can read all th= e rationales 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= /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.m= d > > > > > > > > [5]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a= 9b5104cb7 > > > > > > > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665= c26bc56dd9 > > > > > > > > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72= 428ef9eb608?permalink_comment_id=3D5359072#gistcomment-5359072 > > > > > > > > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_su= pport&diff=3Dprev&oldid=3D70520 > > > > > > > > > > > > > > > > /dev/fd0 > > > > > > > > floppy disk guy > > > > > > > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the= Google Groups "Bitcoin Development Mailing List" group. > > > > > > > > To unsubscribe from this group and stop receiving emails fr= om it, send an email to bitcoindev+...@googlegroups.com. > > > > > > > > To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com. > > > > > > > > > > > > > > -- > > > > > > > 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/msg= id/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3= bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com. > > > > > > > > > > > > -- > > > > > > 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/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mai= l.gmail.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+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/3f12a08f-f303-459a-b50d-36e775372bd3n%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/= FpmE_ze8H8D7ggI8wKMbfhNQ38pmOtOmqoV0MUdeKK3mJ2PN1cQSHPxLyP2TIw194yCpZfTd-h4= F2550KQl12i31En5KTHuJyHXI5GdKD-A%3D%40protonmail.com.