path: root/b8/2be7810027f64d8ab0ec6a59ba3d8c7c4b91ec

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 <bitcoindev+bncBAABBX5J365QMGQEZUXCYJQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <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: <6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk=@protonmail.com>
In-Reply-To: <c411dee9-1937-42fd-bc66-d347ddbff506n@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>
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 <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,

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 <alicexbtong@gmail.com=
> 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 <alice...@gmail.co=
m> 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 <eth...@gmail.com> 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 <bitco...@googlegroups.com> 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 <alice...@g=
mail.com> 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.