path: root/b3/fd602b0a2e5dc6cc1d0cd8b3f2c5eb953e41f7

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 <bitcoindev+bncBAABBYEPUS6AMGQEZYI5JEY@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <alicexbtong@gmail.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
Message-ID: <FpmE_ze8H8D7ggI8wKMbfhNQ38pmOtOmqoV0MUdeKK3mJ2PN1cQSHPxLyP2TIw194yCpZfTd-h4F2550KQl12i31En5KTHuJyHXI5GdKD-A=@protonmail.com>
In-Reply-To: <3f12a08f-f303-459a-b50d-36e775372bd3n@googlegroups.com>
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com> <CAEM=y+V9Gu0n7pLv1d+K1HfaFsB3kXg-LbtppyZG0xjAa7DBaA@mail.gmail.com> <CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA@mail.gmail.com> <BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd27VQfODaemn-jksB8bLFGoM8a70f3xjWI=@protonmail.com> <c411dee9-1937-42fd-bc66-d347ddbff506n@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 <moonsettler@protonmail.com>
Reply-To: moonsettler <moonsettler@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <alicexbtong@gmail.c=
om> 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 <alice...@gmail.co=
m> 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 <alice...@gmai=
l.com> 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 <eth...@gmail.com> 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 <bitco...@googlegroups.com> 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 <alice.=
..@gmail.com> 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.