path: root/89/c8e1e4ee3f1ec1dc638fdc62d24444be668cb0

Delivery-date: Tue, 31 Dec 2024 00:32:36 -0800
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBGOYZ25QMGQEXUMQPIY@googlegroups.com>)
	id 1tSXg3-0003Do-CN
	for bitcoindev@gnusha.org; Tue, 31 Dec 2024 00:32:36 -0800
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e3a0d165daesf18746285276.1
        for <bitcoindev@gnusha.org>; Tue, 31 Dec 2024 00:32:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1735633949; x=1736238749; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Fal+BaIvgY8XYiqPP0zDtCJwm0MHRXPQFrrkQWRlmm8=;
        b=moZB+UUxrNZXN0l/+eAG8YGXr8kslrkJ8FCOzT+gjlCgclLs5qlTleYPjPJFPZexzy
         mz36bv+mbK3j104uF7kljguL/tzMpRYbDYupsSiWWoT/5ioKpsn7hokAY6qw760sjXKb
         AzfLbhVtGHHSf1J8KPAIE/av0qu3OZnohb0jYipvn/2SP3sqM06DMn+owWl3260+TDl7
         bYJ76lzBckP0Qy2OdlH5rYxPHe8aDwwtbyh+smKJ5sefa31Sm03RPH6Jni/+a4AKUR+W
         XQisjMLfai5+VA2fnVezMC+rtR9Xxg+K4KITXAxKjkRvYbtynGSFQ3mQED4wzYsDsLGo
         GEiA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735633949; x=1736238749; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Fal+BaIvgY8XYiqPP0zDtCJwm0MHRXPQFrrkQWRlmm8=;
        b=Pv6tjOLconPHSauk9emzckEonlkfMXCSJg8V/AmReVKJZ07T8vi539HZ9tqiPul7uB
         eI2dFA6Cxjbk0FKI5vT1VVqVveh0dt3nG5Dx+euws4andjahpE/O29SMP/q6/hlM+Jvg
         E+qmoyDSh7M24YFMDHNOc4BEObIUUhYBOXLijPu4ZduxHwaQONZccf8Wqf6v6xC0H2FR
         vmxRtdRX4sWoMc2bQp9dggmVobBgWs0IJSq8qMQh9N/A3R0lnN+3PVcjk0apIBA+mHZn
         UH+1EdznhkUhnQzk83R6G5MbXmReFKrF0v0BsB0hZjFng9ZgMrsQ2AUrNfs41NVKH/3y
         0Pew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735633949; x=1736238749;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=Fal+BaIvgY8XYiqPP0zDtCJwm0MHRXPQFrrkQWRlmm8=;
        b=SH0t3s3JG2vuTZk964g1deR5krfKtl/0QMYA3vcBc1mHmta5dKQDVTy+n2ecqgAAxw
         CkmSHK0R/Xw2Qo/6qwltOQgKUtATozAEx0cA2kcdOKtHFtgdZBPYZMxNZiB6YXkVA9Yp
         gRwrsbumi0l/v3KRQwNzqsKG2DBcHKWh/hM3SIKf4GmmyWZlv4LPZifCuBh+FXVFxPj2
         wG5sLcGiOppzVs6TgNpkRH5796mvkMx3phQm10Z3ov35tuA+//9R1OoASnC6CNaAiR7W
         cqbZkJlmHTQIlP9FfqxOXuyXObNd57CWM9vQ843MnmXhvrrTTKc425apiT+gy8iXd4mS
         cBXw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVo10kMtFGIjFlGJ/g8274masfxEPzv7LB7FErDed3JIM2WzyNrb4KbR7dgz6ud8clMAXuwOosN8pSy@gnusha.org
X-Gm-Message-State: AOJu0YzDp9i4tb2U0jR6tBar0qFIGuhnd4VM5X84q1kSYCNi66bdE3iu
	KiXCOdwc84tfEo04dT65cfYY/SKdIRbqA5x5lE4pY3ZuoXW4p3K/
X-Google-Smtp-Source: AGHT+IFQejO09O3RO6OKGUY5ldGznsrERS3Prfar6m6L5pRy3tJWYJxmpkxZ4ucmrb0Nv0WnwMFZSQ==
X-Received: by 2002:a05:690c:4986:b0:6ef:6107:69b9 with SMTP id 00721157ae682-6f3f80de66bmr294526547b3.7.1735633948568;
        Tue, 31 Dec 2024 00:32:28 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:ae43:0:b0:e48:8566:cdf0 with SMTP id 3f1490d57ef6-e537608e8c6ls1668420276.1.-pod-prod-02-us;
 Tue, 31 Dec 2024 00:32:25 -0800 (PST)
X-Received: by 2002:a05:690c:640b:b0:6ea:6e41:1a9a with SMTP id 00721157ae682-6f3f8136a38mr236689957b3.25.1735633945172;
        Tue, 31 Dec 2024 00:32:25 -0800 (PST)
Received: by 2002:a81:ad03:0:b0:6ef:892f:89f3 with SMTP id 00721157ae682-6f3f57ea50dms7b3;
        Tue, 31 Dec 2024 00:23:29 -0800 (PST)
X-Received: by 2002:a05:690c:4b93:b0:6e9:e097:718c with SMTP id 00721157ae682-6f3f80de76bmr293438797b3.6.1735633408517;
        Tue, 31 Dec 2024 00:23:28 -0800 (PST)
Date: Tue, 31 Dec 2024 00:23:28 -0800 (PST)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com>
Subject: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_917834_1788158514.1735633408289"
X-Original-Sender: alicexbtong@gmail.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: -0.5 (/)

------=_Part_917834_1788158514.1735633408289
Content-Type: multipart/alternative; 
	boundary="----=_Part_917835_1707318338.1735633408289"

------=_Part_917835_1707318338.1735633408289
Content-Type: text/plain; charset="UTF-8"

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 based 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 [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 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. Rearden was 
assigned moderator permissions on 8 December 2024 by Theymos to help me 
with the moderations. Some edits have been approved by other moderators.

Some insights from the table that could help developers working on 
different covenant proposals:

1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_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:

```
======================
SIGHASH_APO
======================

LN SYMMETRY is possible with combination of a few opcodes which 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 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 
predicates on the transaction, and I think the Script is better suited 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 ergonomic 
way to achieve the same goals.

======================
OP_TXHASH
======================

More expressive, many flag configurations, untested and undesirable use 
cases. Unaddressed comments in the BIP and the delay doesn't make sense 
because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same 
thing. Makes hash caching complex, potentially opening up DoS vectors or 
quadratic sighash.

Most templates you'd obtain with various combinations of parameters are 
meaningless. 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 
state.

Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it to 
what people are actually using covenants for, instead of prematurely 
optimizing everything with no data.

======================
OP_VAULT
======================

No demand for vaults. Customized for a specific use case.

======================
OP_CAT
======================

Can be used for various complex scripts including undesirable use cases 
(DEX, AMM and Hashrate Escrow). Enables granular transaction introspection 
through abuse of schnorr signatures and OP_CHECKSIG. Can be used 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 introspection by 
accident, and therefore an ugly version of state-carrying UTXOs, it 
shouldn't be enabled without more ergonomic opcodes for those use cases.

======================
OP_INTERNALKEY
======================

There are 3 'No' in the table, I couldn't find anything relevant in the 
rationales.

======================
OP_PAIRCOMMIT
======================

Adds unnecessary complexity, redundant if OP_CAT is activated in future and 
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.

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.

======================
OP_CHECKTEMPLATEVERIFY
======================

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 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 anything about 
other opcodes and SIGHASH_APO. It is only focused on OP_CAT however 
evaluations exist in the table.
- I [requested][7] Udev (CatSwap) to add details about evaluation of other 
opcodes and SIGHASH_APO.
- Last [edit][8] by Roujiamo (bitdollar) has a rationale with incorrect 
signet stats and seems to be rephrased version of another rationale. 
Evaluation had 'weak' for OP_CTV before adding the rationale.
- An edit with duplicate rationale (in support of OP_CAT) was rejected 
because sharing the link for a rationale submitted by other developer 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 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 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 
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.md
[5]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
[6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
[7]: 
https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permalink_comment_id=5359072#gistcomment-5359072
[8]: 
https://en.bitcoin.it/w/index.php?title=Covenants_support&diff=prev&oldid=70520

/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 from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com.

------=_Part_917835_1707318338.1735633408289
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bitcoin Developers,<br /><br />I had shared covenants support wiki page =
link here on [mailing list][1] in the last week of November 2024. Multiple =
changes were made based on the feedback:<br /><br />- Removed 'community su=
pport' from 'No'. Rephrased definitions for 'Prefer' and 'Evaluating'.<br /=
>- Added LNHANCE category for a combination of opcodes.<br />- Added links =
for BIP drafts and a column for 'rationale'.<br />- Created a separate tabl=
e for evaluations without a rationale.<br /><br />Murch and Gloria shared t=
heir feedback in the bitcoin optech [podcast 333][2]. I have started workin=
g 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 case=
s enabled by [OP_CHECKSIGFROMSTACK][4] alone or in combination with other o=
pcodes like [LN SYMMETRY][5].<br /><br />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 with the moderations. Some edits have =
been approved by other moderators.<br /><br />Some insights from the table =
that could help developers working on different covenant proposals:<br /><b=
r />1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO la=
cks interest among developers, contrary to the belief prior to this exercis=
e.<br />2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mult=
iple covenant proposals.<br />3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECK=
CONTRACTVERIFY are not reviewed by enough developers. OP_PARCOMMIT seems to=
 be controversial at this moment.<br /><br />Objections:<br /><br />```<br =
/>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />S=
IGHASH_APO<br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br /><br />LN SYMMETRY is possible with combination of a few opco=
des which is more efficient. Its not the best option for covenants and cann=
ot be used to improve Ark. Some developers prefer opcodes and not sighash f=
lags.<br /><br />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-reaso=
n (for me) and not flexible. In general, SIGHASH flags are an encoding of s=
pecific predicates on the transaction, and I think the Script is better sui=
ted to carry the predicate. There is no interesting SIGHASH flag that could=
n't be functionally simulated by introspection + CHECKSIGFROMSTACK (or othe=
r Script-based approaches), and that seems to me a much cleaner and ergonom=
ic way to achieve the same goals.<br /><br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />OP_TXHASH<br />=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />More expressive=
, many flag configurations, untested and undesirable use cases. Unaddressed=
 comments in the BIP and the delay doesn't make sense because OP_CHECKTEMPL=
ATEVERIFY can be upgraded later to achieve the same thing. Makes hash cachi=
ng complex, potentially opening up DoS vectors or quadratic sighash.<br /><=
br />Most templates you'd obtain with various combinations of parameters ar=
e meaningless. It implements state-carrying UTXOs in a very dirty way: addi=
ng additional inputs/outputs with no other meaning than "storing some state=
". This is ugly, inefficient, and bloats the UTXO set - and it definitely w=
ill happen if TXHASH is enabled without also enabling a clean way to carry =
state.<br /><br />Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can f=
ine tune it to what people are actually using covenants for, instead of pre=
maturely optimizing everything with no data.<br /><br />=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />OP_VAULT<br />=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />No =
demand for vaults. Customized for a specific use case.<br /><br />=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />OP_CAT<br />=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br=
 />Can be used for various complex scripts including undesirable use cases =
(DEX, AMM and Hashrate Escrow). Enables granular transaction introspection =
through abuse of schnorr signatures and OP_CHECKSIG. Can be used for intere=
sting use cases but alone does it poorly and inefficiently.<br /><br />Peop=
le can and will litter the chain with inefficient/ugly Scripts if activated=
 alone. Since it happens to enable generic introspection by accident, and t=
herefore an ugly version of state-carrying UTXOs, it shouldn't be enabled w=
ithout more ergonomic opcodes for those use cases.<br /><br />=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />OP_INTERNALKEY<=
br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br =
/><br />There are 3 'No' in the table, I couldn't find anything relevant in=
 the rationales.<br /><br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<br />OP_PAIRCOMMIT<br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />Adds unnecessary complex=
ity, redundant if OP_CAT is activated in future and 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 tagg=
ed hash. Some developers prefer OP_CAT.<br /><br />Not convinced it is impo=
ssible that there is no way to simulate CAT with PAIRCOMMIT, nor confident =
how much less powerful PAIRCOMMIT is than CAT.<br /><br />=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br />OP_CHECKTEMPLATEVE=
RIFY<br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br /><br />Limited in scope and not recursive.<br />```<br /><br />I ha=
ve tried my best to remain unbiased in writing this summary and approving e=
dits. There are a few things that I want to share and it could be a result =
of the aggressive marketing:<br /><br />- A spammer had edited the table to=
 remove all evaluations except in favor of OP_CAT and it was rejected.<br /=
>- [Rationale][6] added by Aaron (sCrypt) does not mention anything about o=
ther opcodes and SIGHASH_APO. It is only focused on OP_CAT however evaluati=
ons exist in the table.<br />- I [requested][7] Udev (CatSwap) to add detai=
ls about evaluation of other opcodes and SIGHASH_APO.<br />- Last [edit][8]=
 by Roujiamo (bitdollar) has a rationale with incorrect signet stats and se=
ems to be rephrased version of another rationale. Evaluation had 'weak' for=
 OP_CTV before adding the rationale.<br />- An edit with duplicate rational=
e (in support of OP_CAT) was rejected because sharing the link for a ration=
ale submitted by other developer adds no value in the table.<br /><br />Eva=
luations without a rationale have some 'No' in different cells. Although no=
ne 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 the=
m with a rationale in 2025. Any suggestions to help achieve technical conse=
nsus are most welcome.<br /><br />What's next?<br /><br />- More rationales=
 in the table<br />- Discuss objections on mailing list (if any)<br />- Wor=
kshops<br />- Add a table for economic nodes and their opinion<br />- Build=
 activation client and discuss parameters<br /><br />Finally, I would thank=
 all the developers who added their evaluations in the table and everyone w=
ho shared updates on twitter. It was a coordinated effort to reach some tec=
hnical consensus. You can read all the rationales in detail to understand d=
ifferent perspectives and reasons to support a combination of opcodes over =
others.<br /><br />[1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4T=
I/m/CeEuls2IAQAJ<br />[2]: https://bitcoinops.org/en/podcast/2024/12/17/<br=
 />[3]: https://en.bitcoin.it/wiki/Covenants_Uses<br />[4]: https://github.=
com/bitcoin/bips/blob/master/bip-0348.md<br />[5]: https://gist.github.com/=
Ademan/4a14614fa850511d63a5b2a9b5104cb7<br />[6]: https://gist.github.com/g=
itzhou/dc92c41db1987db16fe665c26bc56dd9<br />[7]: https://gist.github.com/u=
devswap/b768d20d62549922b9e72428ef9eb608?permalink_comment_id=3D5359072#gis=
tcomment-5359072<br />[8]: https://en.bitcoin.it/w/index.php?title=3DCovena=
nts_support&amp;diff=3Dprev&amp;oldid=3D70520<br /><br />/dev/fd0<br />flop=
py disk guy

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com</a>.<br />

------=_Part_917835_1707318338.1735633408289--

------=_Part_917834_1788158514.1735633408289--