From: /dev /fd0 <alicexbtong@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki
Date: Tue, 31 Dec 2024 00:23:28 -0800 (PST) [thread overview]
Message-ID: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> (raw)
[-- 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 --]
next reply other threads:[~2024-12-31 8:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-31 8:23 /dev /fd0 [this message]
2024-12-31 13:17 ` 'moonsettler' via Bitcoin Development Mailing List
2025-01-01 1:46 ` /dev /fd0
2025-01-01 18:11 ` Ethan Heilman
2025-01-02 1:22 ` /dev /fd0
2025-01-02 13:40 ` 'moonsettler' via Bitcoin Development Mailing List
2025-01-02 15:16 ` /dev /fd0
2025-01-03 11:59 ` 'moonsettler' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com \
--to=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox