Summary: Covenants Support - Bitcoin Wiki

Summary: Covenants Support - Bitcoin Wiki
2024-12-31 13:17 ` 'moonsettler' via Bitcoin Development Mailing List
  
From: /dev /fd0 @ 2024-12-31  8:23 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 7610 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 8341 bytes --]

 permalink raw reply	[|nested]
2024-12-31  8:23 [bitcoindev] Summary: Covenants Support - Bitcoin Wiki /dev /fd0

  2025-01-01  1:46   ` /dev /fd0
  2025-01-01 18:11   ` Ethan Heilman
  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2024-12-31 13:17 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

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 soon. The only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!

======================
OP_PARCOMMIT 
======================

> 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 worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness malleability.

> 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.

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

> 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•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 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.

-- 
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/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com.


 permalink raw reply	[|nested]
2024-12-31 13:17 ` 'moonsettler' via Bitcoin Development Mailing List

  2025-01-01 18:11   ` Ethan Heilman
  
From: /dev /fd0 @ 2025-01-01  1:46 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 11412 bytes --]

Hi monnsettler,

I have never mentioned this as voting in any of my posts. You are free to 
build activation clients that nobody will run. 

/dev/fd0
floppy disk guy

On Tuesday, December 31, 2024 at 7:53:35 PM UTC+5:30 moonsettler 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 soon. The 
> only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort 
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
>
> ======================
> OP_PARCOMMIT 
> ======================
>
> > 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 worth 
> noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from 
> those 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 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-element 
> commitments in script. PAIRCOMMIT is not significantly more complicated 
> 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 
> witness malleability.
>
> > 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.
>
> ======================
> OP_VAULT
> ======================
>
> > 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 [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+...@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 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/aa731d1c-cadb-4424-839f-f13b4f8bf079n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15425 bytes --]

 permalink raw reply	[|nested]
2024-12-31 13:17 ` 'moonsettler' via Bitcoin Development Mailing List
  2025-01-01  1:46   ` /dev /fd0

  2025-01-02  1:22     ` /dev /fd0
  
From: Ethan Heilman @ 2025-01-01 18:11 UTC (permalink / raw)
  To: moonsettler;  Bitcoin Development Mailing List

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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness 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 Bitcoin
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 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 arbitrary
computation by building STARKs with PAIRCOMMIT merkle trees? If not,
why not?

That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
Mailing List <bitcoindev@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 soon. The only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
>
> ======================
> OP_PARCOMMIT
> ======================
>
> > 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 worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness malleability.
>
> > 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.
>
> ======================
> OP_VAULT
> ======================
>
> > 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•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 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.
>
> --
> 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/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.com.


 permalink raw reply	[|nested]
2025-01-01 18:11   ` Ethan Heilman

  2025-01-02 13:40       ` 'moonsettler' via Bitcoin Development Mailing List
  
From: /dev /fd0 @ 2025-01-02  1:22 UTC (permalink / raw)
  To: Ethan Heilman;  moonsettler, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 14818 bytes --]

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 of all
the rationales and not my person opinion.

/dev/fd0
floppy disk guy

On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth3rs@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-element
> commitments in script. PAIRCOMMIT is not significantly more complicated
> 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
> witness 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 Bitcoin
> 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 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 arbitrary
> computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> why not?
>
> That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
> Mailing List <bitcoindev@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 soon.
> The only way to change that is to demonstrate actual harm. You liking
> 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
> 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 you decide you want to run an alternative activation effort
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
> >
> > ======================
> > OP_PARCOMMIT
> > ======================
> >
> > > 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 worth
> noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from
> those 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 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-element
> commitments in script. PAIRCOMMIT is not significantly more complicated
> 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
> witness malleability.
> >
> > > 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.
> >
> > ======================
> > OP_VAULT
> > ======================
> >
> > > 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•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
> 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
> .
> >
> > --
> > 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/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 18646 bytes --]

 permalink raw reply	[|nested]
2025-01-02  1:22     ` /dev /fd0

  2025-01-02 15:16         ` /dev /fd0
  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-01-02 13:40 UTC (permalink / raw)
  To: /dev /fd0;  Ethan Heilman, Bitcoin Development Mailing List

Hi Floppy,

Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 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 more 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 observation in any shape or form. It would provide optimization for many contracts and use cases even if we had CAT. I explained this to you in private first, 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 <alicexbtong@gmail•com> wrote:

> 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 of all the rationales and not my person opinion.
> 
> /dev/fd0
> floppy disk guy
> 
> On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman <eth3rs@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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness 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 Bitcoin
> > 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 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 arbitrary
> > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > why not?
> > 
> > That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
> > Mailing List <bitcoindev@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 soon. The only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > >
> > > ======================
> > > OP_PARCOMMIT
> > > ======================
> > >
> > > > 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 worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness malleability.
> > >
> > > > 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.
> > >
> > > ======================
> > > OP_VAULT
> > > ======================
> > >
> > > > 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•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 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.
> > >
> > > --
> > > 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/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send an email to bitcoindev+unsubscribe@googlegroups•com.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/BhJt9xz8jFdkQDtIMh4BRavAACrNBjRRAoOMtw2PBReaazmhZcy7PTZcMu-rqdxTp7Lh1yqSkd27VQfODaemn-jksB8bLFGoM8a70f3xjWI%3D%40protonmail.com.


 permalink raw reply	[|nested]
2025-01-02 13:40       ` 'moonsettler' via Bitcoin Development Mailing List

  2025-01-03 11:59           ` 'moonsettler' via Bitcoin Development Mailing List
  
From: /dev /fd0 @ 2025-01-02 15:16 UTC ( / )
  To: Bitcoin Development Mailing List




Hi moonsettler,

>  Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 
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 [rationale][1]. 
LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.

>  Calling it "unnecessary complexity" is not a valid technical observation 
in any shape or form. It would provide optimization for many contracts and 
use cases even if we had CAT. I explained this to you in private first, yet 
you keep insisting on this completely invalid objection.

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 who finds this opcode irrelevant. Please respect the developers who 
shared their evaluations in the table even if you disagree with them. If 
you cannot 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 
email.

/dev/fd0
floppy disk guy 

[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 PM UTC+5:30 moonsettler wrote:

> Hi Floppy,
>
> Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 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 more 
> 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 observation 
> in any shape or form. It would provide optimization for many contracts and 
> use cases even if we had CAT. I explained this to you in private first, 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...@gmail•com> 
> wrote:
>
> > 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 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> 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-element 
> commitments in script. PAIRCOMMIT is not significantly more complicated 
> 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 
> witness 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 Bitcoin
> > > 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 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 arbitrary
> > > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > > why not?
> > > 
> > > That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
> > > 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 
> soon. The only way to change that is to demonstrate actual harm. You liking 
> 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 
> 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 you decide you want to run an alternative activation effort 
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > >
> > > > ======================
> > > > OP_PARCOMMIT
> > > > ======================
> > > >
> > > > > 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 worth 
> noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from 
> those 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 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-element 
> commitments in script. PAIRCOMMIT is not significantly more complicated 
> 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 
> witness malleability.
> > > >
> > > > > 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.
> > > >
> > > > ======================
> > > > OP_VAULT
> > > > ======================
> > > >
> > > > > 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 [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+...@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 Google 
> 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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send 
> an email to bitcoindev+...@googlegroups•com.
> > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.com.
2025-01-02 15:16         ` /dev /fd0

  2025-01-03 13:58             ` /dev /fd0
  2025-01-14 14:14             ` /dev /fd0
  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-01-03 11:59 UTC (permalink / raw)
  To: /dev /fd0;  Bitcoin Development Mailing List

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 even 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. 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 [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
> 
> > Calling it "unnecessary complexity" is not a valid technical observation in any shape or form. It would provide optimization for many contracts and use cases even if we had CAT. I explained this to you in private first, yet you keep insisting on this completely invalid objection.
> 
> 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 who finds this opcode irrelevant. Please respect the developers who shared their evaluations in the table even if you disagree with them. If you cannot 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 email.
> 
> /dev/fd0
> floppy disk guy
> 
> [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 PM UTC+5:30 moonsettler wrote:
> 
> > Hi Floppy,
> > 
> > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 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 more 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 observation in any shape or form. It would provide optimization for many contracts and use cases even if we had CAT. I explained this to you in private first, 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...@gmail•com> wrote:
> > 
> > > 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 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> 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness 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 Bitcoin
> > > > 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 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 arbitrary
> > > > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > > > why not?
> > > >
> > > > That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
> > > > 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 soon. The only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > > >
> > > > > ======================
> > > > > OP_PARCOMMIT
> > > > > ======================
> > > > >
> > > > > > 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 worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness malleability.
> > > > >
> > > > > > 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.
> > > > >
> > > > > ======================
> > > > > OP_VAULT
> > > > > ======================
> > > > >
> > > > > > 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 [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+...@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 Google 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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send an email to bitcoindev+...@googlegroups•com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6Jm_AoIIskhEfyAwJFVFmzzA1iJJ3h51yCC8TwgO_MhV-ARzL9s7fVynKdN0-rNqNrN3kYsklxTZDGuko8LMsT0SW-Idy7tdA_u_e0s_Zsk%3D%40protonmail.com.


 permalink raw reply	[|nested]
2025-01-03 11:59           ` 'moonsettler' via Bitcoin Development Mailing List

  2025-01-16 12:32               ` 'moonsettler' via Bitcoin Development Mailing List
  2025-01-14 14:14             ` /dev /fd0
  
From: /dev /fd0 @ 2025-01-03 13:58 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 21132 bytes --]

Hi moonsettler,

Maybe you missed this part in the original post:

> 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)

Let me know if you know a better way to reach "consensus". This mailing 
list post was intended to discuss everything because I am done with 
consensus on twitter.

/dev/fd0
floppy disk guy

On Friday, January 3, 2025 at 5:45:29 PM UTC+5:30 moonsettler wrote:

> 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 
> even 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 <alice...@gmail•com> 
> wrote:
>
> > Hi moonsettler,
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 
> 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 
> [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
> > 
> > > Calling it "unnecessary complexity" is not a valid technical 
> observation in any shape or form. It would provide optimization for many 
> contracts and use cases even if we had CAT. I explained this to you in 
> private first, yet you keep insisting on this completely invalid objection.
> > 
> > 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 who finds this opcode irrelevant. Please respect the developers who 
> shared their evaluations in the table even if you disagree with them. If 
> you cannot 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 
> email.
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > [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 PM UTC+5:30 moonsettler wrote:
> > 
> > > Hi Floppy,
> > > 
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 
> 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 
> more 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 
> observation in any shape or form. It would provide optimization for many 
> contracts and use cases even if we had CAT. I explained this to you in 
> private first, 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...@gmail•com> wrote:
> > > 
> > > > 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 
> 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> 
> 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-element commitments in script. PAIRCOMMIT is not significantly more 
> complicated 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 witness 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 
> Bitcoin
> > > > > 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 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 
> arbitrary
> > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If 
> not,
> > > > > why not?
> > > > >
> > > > > That said, I have not heard any argument against PAIRCOMMIT from 
> 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 AM 'moonsettler' via Bitcoin 
> Development
> > > > > 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 
> soon. The only way to change that is to demonstrate actual harm. You liking 
> 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 
> 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 you decide you want to run an alternative activation effort 
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > > > >
> > > > > > ======================
> > > > > > OP_PARCOMMIT
> > > > > > ======================
> > > > > >
> > > > > > > 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 
> worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" 
> from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more 
> complicated 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 witness malleability.
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > ======================
> > > > > > OP_VAULT
> > > > > > ======================
> > > > > >
> > > > > > > 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 [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+...@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 
> Google 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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, 
> send an email to bitcoindev+...@googlegroups•com.
> > > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send 
> an email to bitcoindev+...@googlegroups•com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3f12a08f-f303-459a-b50d-36e775372bd3n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 30593 bytes --]

 permalink raw reply	[|nested]
2025-01-03 11:59           ` 'moonsettler' via Bitcoin Development Mailing List
  2025-01-03 13:58             ` /dev /fd0

  
From: /dev /fd0 @ 2025-01-14 14:14 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 20658 bytes --]

We have been discussing the objections shared by Jonas Nick in his 
rationale: 
https://gist.github.com/jonasnick/e9627f56d04732ca83e94d448d4b5a51

Feel free to comment if you'd like to add something.

/dev/fd0
floppy disk guy

On Friday, January 3, 2025 at 5:45:29 PM UTC+5:30 moonsettler wrote:

> 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 
> even 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 <alice...@gmail•com> 
> wrote:
>
> > Hi moonsettler,
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 
> 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 
> [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
> > 
> > > Calling it "unnecessary complexity" is not a valid technical 
> observation in any shape or form. It would provide optimization for many 
> contracts and use cases even if we had CAT. I explained this to you in 
> private first, yet you keep insisting on this completely invalid objection.
> > 
> > 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 who finds this opcode irrelevant. Please respect the developers who 
> shared their evaluations in the table even if you disagree with them. If 
> you cannot 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 
> email.
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > [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 PM UTC+5:30 moonsettler wrote:
> > 
> > > Hi Floppy,
> > > 
> > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 
> 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 
> more 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 
> observation in any shape or form. It would provide optimization for many 
> contracts and use cases even if we had CAT. I explained this to you in 
> private first, 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...@gmail•com> wrote:
> > > 
> > > > 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 
> 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> 
> 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-element commitments in script. PAIRCOMMIT is not significantly more 
> complicated 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 witness 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 
> Bitcoin
> > > > > 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 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 
> arbitrary
> > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If 
> not,
> > > > > why not?
> > > > >
> > > > > That said, I have not heard any argument against PAIRCOMMIT from 
> 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 AM 'moonsettler' via Bitcoin 
> Development
> > > > > 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 
> soon. The only way to change that is to demonstrate actual harm. You liking 
> 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 
> 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 you decide you want to run an alternative activation effort 
> with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > > > >
> > > > > > ======================
> > > > > > OP_PARCOMMIT
> > > > > > ======================
> > > > > >
> > > > > > > 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 
> worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" 
> from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more 
> complicated 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 witness malleability.
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > ======================
> > > > > > OP_VAULT
> > > > > > ======================
> > > > > >
> > > > > > > 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 [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+...@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 
> Google 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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, 
> send an email to bitcoindev+...@googlegroups•com.
> > > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send 
> an email to bitcoindev+...@googlegroups•com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c7486012-79a3-46e4-a310-a3d0edb47e97n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 30155 bytes --]

 permalink raw reply	[|nested]
2025-01-03 13:58             ` /dev /fd0

  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-01-16 12:32 UTC (permalink / raw)
  To: /dev /fd0;  Bitcoin Development Mailing List

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•com> wrote:

> Hi moonsettler,
> Maybe you missed this part in the original post:
> 
> > 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)
> 
> Let me know if you know a better way to reach "consensus". This mailing list post was intended to discuss everything because I am done with consensus on twitter.
> 
> /dev/fd0
> floppy disk guy
> On Friday, January 3, 2025 at 5:45:29 PM UTC+5:30 moonsettler wrote:
> 
> > 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 even 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 <alice...@gmail•com> wrote:
> > 
> > > Hi moonsettler,
> > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 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 [rationale][1]. LNHANCE is not an opcode. CTV and CSFS enable LN SYMMETRY.
> > >
> > > > Calling it "unnecessary complexity" is not a valid technical observation in any shape or form. It would provide optimization for many contracts and use cases even if we had CAT. I explained this to you in private first, yet you keep insisting on this completely invalid objection.
> > >
> > > 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 who finds this opcode irrelevant. Please respect the developers who shared their evaluations in the table even if you disagree with them. If you cannot 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 email.
> > >
> > > /dev/fd0
> > > floppy disk guy
> > >
> > > [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 PM UTC+5:30 moonsettler wrote:
> > >
> > > > Hi Floppy,
> > > >
> > > > Neither INTERNALKEY nor PAIRCOMMIT enables LN-Symmetry, LNhance does. 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 more 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 observation in any shape or form. It would provide optimization for many contracts and use cases even if we had CAT. I explained this to you in private first, 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...@gmail•com> wrote:
> > > >
> > > > > 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 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> 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness 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 Bitcoin
> > > > > > 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 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 arbitrary
> > > > > > computation by building STARKs with PAIRCOMMIT merkle trees? If not,
> > > > > > why not?
> > > > > >
> > > > > > That said, I have not heard any argument against PAIRCOMMIT from 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 AM 'moonsettler' via Bitcoin Development
> > > > > > 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 soon. The only way to change that is to demonstrate actual harm. You liking 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 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 you decide you want to run an alternative activation effort with CAT instead of PAIRCOMMIT feel free to fork our repo!
> > > > > > >
> > > > > > > ======================
> > > > > > > OP_PARCOMMIT
> > > > > > > ======================
> > > > > > >
> > > > > > > > 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 worth noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from those 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 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-element commitments in script. PAIRCOMMIT is not significantly more complicated 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 witness malleability.
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > ======================
> > > > > > > OP_VAULT
> > > > > > > ======================
> > > > > > >
> > > > > > > > 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 [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+...@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 Google 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/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-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, send an email to bitcoindev+...@googlegroups•com.
> > > > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.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, send an email to bitcoindev+...@googlegroups•com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c411dee9-1937-42fd-bc66-d347ddbff506n%40googlegroups.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3f12a08f-f303-459a-b50d-36e775372bd3n%40googlegroups.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, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/FpmE_ze8H8D7ggI8wKMbfhNQ38pmOtOmqoV0MUdeKK3mJ2PN1cQSHPxLyP2TIw194yCpZfTd-h4F2550KQl12i31En5KTHuJyHXI5GdKD-A%3D%40protonmail.com.


 permalink raw reply	[|nested]