path: root/7f/965bdae865b3daba2962501414886c376471de

Delivery-date: Tue, 31 Dec 2024 06:23:42 -0800
Received: from mail-qt1-f189.google.com ([209.85.160.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBZH4Z65QMGQE5OSVKAA@googlegroups.com>)
	id 1tSd9p-0001Zu-DM
	for bitcoindev@gnusha.org; Tue, 31 Dec 2024 06:23:42 -0800
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-467a4f0b53bsf21618811cf.3
        for <bitcoindev@gnusha.org>; Tue, 31 Dec 2024 06:23:40 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1735655015; cv=pass;
        d=google.com; s=arc-20240605;
        b=D2PlARDnHtzigb3xwtIvSodgGgR3bx+8KYKjfW8yvmF0jeDfMTcAHm6DeUVSMDTdpl
         V20ObNJNHaLAcVC7rpyGU0zisoWMQ/gshuQiaS//0LPZCACH5fb5VbhVWDh3v1Mktsce
         fe26+VCCQISErJ6P8XwX6hP61AFDTn45ShAe65vDmnJtfdG8B5tRZPOGlZ/GCSHKHf1K
         AFjD9k58EV6Yk+5gyaEBqX3Je6wMDDJU9aws+JQiASWjRQOtAyu7UNKYzTvBUbbVOcrc
         2F0Fve4CKWp/11QvTe9Pk3E7BLSVpaIDX2HdeDuI1GBVsmlRNs09OwpbrmvEz47RuHQ4
         KTWQ==
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
         :from:to:date:dkim-signature;
        bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=;
        fh=zPkSYs7al+ynzuaR1g6X8iyRPg+2jLBd/HsqyDDJuE0=;
        b=cjr1SUnmB2Ars4tMtV/701MZP1ZW2azTOgr+HT2tTSpnzpK2by3IMcGmg8pXq5DUFf
         qtaD4YBrQm6As9ijK3/uPm4kEt+VOpzOXuZCyPcw+yQKytgEdx/lpxXNaiULcSiqkh7R
         +f2elqbFHKHQy/LE+1Ju6vqFlQ+qaiZesS481/9nAa4e6wwcn71GFmO9xgVQwzP9r0G9
         P3Y92Fj4hCCBC8nEju/jwYh5vxc2nRcI3zTPNsjvtUC9HfHQeGxKGUaXRpmKBnC9e89C
         4xTHUkZ9jMeAF2ZcX5qqIviT/T5gZLY2Vb1NwLxC/OP/6gPIvlAj7qwX1m9zsNCT3LGq
         vZCg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Dcia8T3h;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 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=1735655015; x=1736259815; 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:from:to:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=;
        b=rCixM0Wc+kKAA6kJADIQ30NsxTk9rDCXSRsm+AmrHh+INI+7TUCApDaQiYmzOTlfnz
         Js8DB1eznyCLPLJ6o0sfcbSeaSm+qldBomjrVc2YJ1IW9rahhSQcJPuRWXZBDjWqPCFv
         PpCSzVo4+5v0Kwbv/Jq+4XnRCJ3LF2z9GrVWF/IpzvhAaXOAgI6FgzLINZxQbR5kFcpp
         FGNDd7kEyI7jet0ufG36roBQU22cr/z7CSbTxe5WneowFw9OP24dgsmWb9Fc1oNTDuVt
         Bk4VlsY2Li9xH3glCciq2x9XuJLu1ppVdSFSzlEpWZrcaty32GznFIaMVOw0UDlrlZXk
         s14w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735655015; x=1736259815;
        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:from:to:date:x-beenthere
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=;
        b=Irkjm+B8x6FiQHFYoA1zr3T1ufpcj2QYUoCYL1HvVKSJBLaY8ti4JLd5ILLFGz1LbN
         SwWj+NrC8FRKIOb2AcCkB1dCgBBNjW3HgQP9WwhuLzs8Nel5KZdlONcBQDvy7nzZBfMO
         xIuPC+TfysKvYINBeuJ498zOEenznAkzlPo8HDapG5Rpbt/VRrfboMn2PHCucn+I2A9J
         kMNOtCKj/iutGc84P0omnscB8xNz191ob/c7hqzJ36VyQdNfAQwgyQXK9f5yKcfEuS4W
         vI/uCbWJI9fkAxcm8pgIlIf/NdIcS4VRqWr5mCzN68bbhmujrJpWZMVmROpv194C05C4
         55Kg==
X-Forwarded-Encrypted: i=2; AJvYcCUr2x4rWQbVLN1bPFGHh3DqXxeR3MWbKk6Hc8r72224+5of5+HQ21WEgiG4Dbxw/OSSrqE1KPCBgbtW@gnusha.org
X-Gm-Message-State: AOJu0YwqcVOZzPhdBlD0wzf6zP2iDXQOXatfuDulR/jcyYFGaFMLR1TE
	bCuVGJ05XapxbA3jXMmsCt1xOQ70gT04R6an3j6fnOQnvRo127OL
X-Google-Smtp-Source: AGHT+IGm8idcWG27gDafbVl86MJ9TOcpd4ija5ACUKtaJ7hUSPAyKwL0f0BPNIzHFrU35Q15P+7RWw==
X-Received: by 2002:a05:622a:587:b0:467:7cda:9388 with SMTP id d75a77b69052e-46a4a8f663emr584654481cf.31.1735655014813;
        Tue, 31 Dec 2024 06:23:34 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ac8:4709:0:b0:466:98fc:1e3f with SMTP id d75a77b69052e-46a3b15d199ls19928061cf.1.-pod-prod-04-us;
 Tue, 31 Dec 2024 06:23:32 -0800 (PST)
X-Received: by 2002:a05:620a:28c7:b0:7b1:4fba:b02e with SMTP id af79cd13be357-7b9ba6efacfmr5978254885a.12.1735655012049;
        Tue, 31 Dec 2024 06:23:32 -0800 (PST)
Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14ems85a;
        Tue, 31 Dec 2024 05:17:33 -0800 (PST)
X-Received: by 2002:a05:600c:a0a:b0:434:a04d:1670 with SMTP id 5b1f17b1804b1-436678f5775mr376805225e9.0.1735651052019;
        Tue, 31 Dec 2024 05:17:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1735651052; cv=none;
        d=google.com; s=arc-20240605;
        b=F9W36Tz7gRaTyL4kWu3pOErBZYQYaXbCwap8378PWzXECltHXd43dUC3cj6YP6+9F8
         9Wf1u7Rj3Vx8QbXaWSxZDHPS2q8CQcKDS2B/S7f8qJtN58c4UhuWMR3IJwjpBQ2Wprii
         T3Ew8jvSjdlDK/umNowdERbGGHhG4HSUE9+IcHlwC1t5foNrHaLl51Gk/tkeMvqSNMUV
         ETiu7wqDtoaa+M2HYLZ0vZKX6cgJ3MI4piHmbLTvh5Sqrg9p1RyJdkFReJfhVHT0pN0K
         Vp83BLN9ODYJ6lbqe3Mhr8zlfVv7hQQtrmNoomN6/oJjkXwFwbwGMuIVumBmGGO4+iva
         iP0w==
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:from:to:date:dkim-signature;
        bh=RxAHGZgLgc26tkSd64BpgHcHirC0iM4psdfOrqh1IFI=;
        fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
        b=KfYa9W3jaEruqXqz/cho417ozwXmDAkUuSF78+VYtw0VlEJbDMLKec3BnUH1jAuv0n
         ugWBkepkVtOAhwR/+D2qmXgKOJdsRevrh5W6l3FtgxoVRrHYzqSYZJR6E18/T8oHobzl
         KjqjYWpgWQF2kZHyvDGxMQXxNotWo/GORxaL+65008eSpXr+bQGmKhbiNSf4D6heJ5jS
         0plrjSOfhjGXcjT94ofnzpWV8YsM/j+r+nXR5TUpZV4kopfrouYkeGXrHPAeoH8fMt3G
         kvdhLKrWjREnTp97V/SF36zGLe7zP/5aW7VqevDC7aAK0AMUOM6R9ZoRAAQIdmo8d5xT
         4IIg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Dcia8T3h;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4368eaa584fsi9419585e9.0.2024.12.31.05.17.31
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 31 Dec 2024 05:17:31 -0800 (PST)
Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19;
Date: Tue, 31 Dec 2024 13:17:26 +0000
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
Message-ID: <rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac=@protonmail.com>
In-Reply-To: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
Feedback-ID: 38540639:user:proton
X-Pm-Message-ID: d9e884b6315b37dd14bd6387449b4864620e4df7
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=Dcia8T3h;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates
 185.70.43.19 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 All,

One thing I would like to make clear before people get the wrong idea and t=
hink this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is part o=
f LNhance and will be part of the activation client we release soon. The on=
ly way to change that is to demonstrate actual harm. You liking something e=
lse more, is your problem. What you can do about it, is write your activati=
on client and try to gain consensus on that. There are plenty of version bi=
ts available. Replacing PAIRCOMMIT with CAT would be really easy, but while=
 CAT is indeed very popular and has a wide support base it is also strongly=
 opposed by many who did not choose to participate. I'm not convinced that =
this table represents actual developer, let alone ecosystem consensus. If y=
ou decide you want to run an alternative activation effort with 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=20
=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. Litera=
lly nobody managed to come up with a single use case anyone worth noting ob=
jects to for PAIRCOMMIT. Also inclined to ignore the "No" from those that p=
refer CAT as plain trolling. This BIP is young, there is a clear correlatio=
n between the age of the proposals and their support with the sole exceptio=
n of APO.

> Adds unnecessary complexity

That's a subjective value judgement it enables something that was no possib=
le before which is interacting with Merkle trees and multi-element commitme=
nts in script. PAIRCOMMIT is not significantly more complicated than CAT, a=
nd in a lot of actual use cases CAT was desired for it's more complex and r=
esource intensive to safely use CAT than PAIRCOMMIT due to witness malleabi=
lity.

> Not convinced it is impossible that there is no way to simulate CAT with =
PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is 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 <alicexbtong@gmail.co=
m> wrote:

> Hi Bitcoin Developers,
>=20
> I had shared covenants support wiki page link here on [mailing list][1] i=
n the last week of November 2024. Multiple changes were made based on the f=
eedback:
>=20
> - Removed 'community support' from 'No'. Rephrased definitions for 'Prefe=
r' 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.
>=20
> Murch and Gloria shared their feedback in the bitcoin optech [podcast 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 lis=
t does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] alone or =
in combination with other opcodes like [LN SYMMETRY][5].
>=20
> I had verified each entry to avoid spam and fake evaluations. Rearden was=
 assigned moderator permissions on 8 December 2024 by Theymos to help me wi=
th the moderations. Some edits have been approved by other moderators.
>=20
> Some insights from the table that could help developers working on differ=
ent covenant proposals:
>=20
> 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO lack=
s interest among developers, contrary to the belief prior to this exercise.
> 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of multiple c=
ovenant proposals.
> 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not revie=
wed by enough developers. OP_PARCOMMIT seems to be controversial at this mo=
ment.
>=20
> Objections:
>=20
> ```
> =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
>=20
> LN SYMMETRY is possible with combination of a few opcodes which is more e=
fficient. Its not the best option for covenants and cannot be used to impro=
ve Ark. Some developers prefer opcodes and not sighash flags.
>=20
> Seems to be the result of an attempt to fix signatures to make them work =
for a specific use-case, but the end-result is hard-to-reason (for me) and =
not flexible. In general, SIGHASH flags are an encoding of specific predica=
tes on the transaction, and I think the Script is better suited to carry th=
e predicate. There is no interesting SIGHASH flag that couldn't be function=
ally simulated by introspection + CHECKSIGFROMSTACK (or other Script-based =
approaches), and that seems to me a much cleaner and ergonomic way to achie=
ve the same goals.
>=20
> =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
>=20
> More expressive, many flag configurations, untested and undesirable use c=
ases. Unaddressed comments in the BIP and the delay doesn't make sense beca=
use OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same thing.=
 Makes hash caching complex, potentially opening up DoS vectors or quadrati=
c sighash.
>=20
> Most templates you'd obtain with various combinations of parameters are m=
eaningless. It implements state-carrying UTXOs in a very dirty way: adding =
additional inputs/outputs with no other meaning than "storing some state". =
This is ugly, inefficient, and bloats the UTXO set - and it definitely will=
 happen if TXHASH is enabled without also enabling a clean way to carry sta=
te.
>=20
> Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it to w=
hat people are actually using covenants for, instead of prematurely optimiz=
ing everything with no data.
>=20
> =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
>=20
> No demand for vaults. Customized for a specific use case.
>=20
> =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
>=20
> Can be used for various complex scripts including undesirable use cases (=
DEX, AMM and Hashrate Escrow). Enables granular transaction introspection t=
hrough abuse of schnorr signatures and OP_CHECKSIG. Can be used for interes=
ting use cases but alone does it poorly and inefficiently.
>=20
> People can and will litter the chain with inefficient/ugly Scripts if act=
ivated alone. Since it happens to enable generic introspection by accident,=
 and therefore an ugly version of state-carrying UTXOs, it shouldn't be ena=
bled without more ergonomic opcodes for those use cases.
>=20
> =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
>=20
> There are 3 'No' in the table, I couldn't find anything relevant in the r=
ationales.
>=20
> =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
>=20
> Adds unnecessary complexity, redundant if OP_CAT is activated in future a=
nd added for specific use case. LN SYMMETRY is possible without this opcode=
. It does not compose with anything that involves transaction introspection=
 due to its specified tagged hash. Some developers prefer OP_CAT.
>=20
> Not convinced it is impossible that there is no way to simulate CAT with =
PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than CAT.
>=20
> =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
>=20
> Limited in scope and not recursive.
> ```
>=20
> I have tried my best to remain unbiased in writing this summary and appro=
ving edits. There are a few things that I want to share and it could be a r=
esult of the aggressive marketing:
>=20
> - A spammer had edited the table to remove all evaluations except in favo=
r of OP_CAT and it was rejected.
> - [Rationale][6] added by Aaron (sCrypt) does not mention anything about =
other opcodes and SIGHASH_APO. It is only focused on OP_CAT however evaluat=
ions exist in the table.
> - I [requested][7] Udev (CatSwap) to add details about evaluation of othe=
r opcodes and SIGHASH_APO.
> - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incorrect s=
ignet stats and seems to be rephrased version of another rationale. Evaluat=
ion had 'weak' for OP_CTV before adding the rationale.
> - An edit with duplicate rationale (in support of OP_CAT) was rejected be=
cause sharing the link for a rationale submitted by other developer adds no=
 value in the table.
>=20
> Evaluations without a rationale have some 'No' in different cells. Althou=
gh none of them are backed by a rationale so cannot be considered for conse=
nsus discussion. The table is still updated regularly so you may see some o=
f them with a rationale in 2025. Any suggestions to help achieve technical =
consensus are most welcome.
>=20
> What's next?
>=20
> - 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
>=20
> Finally, I would thank all the developers who added their evaluations in =
the table and everyone who shared updates on twitter. It was a coordinated =
effort to reach some technical consensus. You can read all the rationales i=
n detail to understand different perspectives and reasons to support a comb=
ination of opcodes over others.
>=20
> [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.md
> [5]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
> [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?pe=
rmalink_comment_id=3D5359072#gistcomment-5359072
> [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=3Dp=
rev&oldid=3D70520
>=20
> /dev/fd0
> floppy disk guy
>=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/38a6f252-afe9-4155-a341-11a42a9a9007n%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/=
rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC=
6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com.