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