Rationale for the Covenants Support Wiki Page
This document is the result of many conversations with many bitcoin devs over the last several years. My positions on these topics are constantly evolving as I learn more information. Since, up till now, I am not a bitcoin core contributor, my review of the actual code has been rather sparse and I am mostly relying on the opinions of others to inform my views as to the technical soundness of the actual implementations. Thus, this document takes a more high-level, "Concept ACK/Concept NACK" approach than an "ACK/NACK" one.
- payments and custody centralizing
- blocks are too small for all the coffees, Lightning is hard to use (for various reasons)
- we need to scale Lightning to a global userbase, but there isn’t enough block space for 8 billion channels because 8 billion channel opens would take 80 years if we can only confirm 100M txs per year (2000 txs/block, 144 blocks/day, 365 days/year)
- Onboarding new users to bitcoin is painful and embarrassing during high fees because you’re forced to recommend Wallet of Satoshi (custodial) or Phoenix (requires an upfront fee for the channel opening tx)
All of these things can be fixed by some combination of covenant features.
- Spam (we don’t want altcoin Ponzis to have more convenient ways of spamming the chain)
- Dexes/Hashrate Escrows/AMMs
- We don’t want to turn bitcoin into a cesspool of gambling
- We don’t want to enable centralizing MEV
- We don’t want bitcoin to be the new ETH
- The tech and the culture are intertwined.
- "Come on, we can’t expect everyone to run their own node!"
- "Come on, we can’t expect everyone to hold their own keys!"
- "Come on, we can’t expect everyone to process their own payments!"
- There are already people saying these things, and we need to reverse this trend.
- If the tech supports decentralization, then the culture will value decentralization.
- If the tech doesn’t stay decentralized at scale, then the culture will stop thinking decentralization is important.
- The segwit and taproot upgrades enabled harmful scam/spam use cases which have damaged bitcoin’s usefulness as money. The bitcoin community has so far been unwilling or unable to activate proper mempool filtering to counter this abuse.
- Given this, we must proceed with the utmost caution as consensus changes no longer appear to be “reversible”, as they were in Satoshi’s era.
- Anything we activate on the consensus layer can be assumed to be permanent.
- We must activate only features that expand bitcoin’s usefulness as money, while discouraging use cases that harm bitcoin’s usefulness as money (such as the token spam that started in Feb 2023).
Prefer
- Well reviewed and generally regarded as safe
- Doesn’t do much on its own, apart from enhancing Ark and just generally being a convenient building block
- Still perfectly fine to activate by itself, given how powerful it is when combined with other new primitives (which can always be activated at a later time).
- Together with CSFS, emulates
APOAS|ALL, which enables Symmetry Channels and efficient PTLCs.
Acceptable
- Basically just a more elegant OP_CHECKSIG, as it separates hashing the tx from checking the signature.
- Exciting to me because together with CTV it enables Symmetry Channels, which are desperately needed for massive improvements to the scalability and maintainability of the Lightning Network.
Acceptable
- Simple and easy to reason about (takes the top two stack elements and tag-hashes their concatenation)
- Needed in order to enable Symmetry Channels without requiring all Lightning nodes and watchtowers to store the settlement tapleaf hash for all previous states in all open channels, and without needing the taproot annex or OP_RETURN (which would be used for Symmetry Channels if OP_PC is not enabled).
- Since removing the requirement for all Lightning nodes and watchtowers to store previous states is one of the main benefits of Symmetry Channels, I’m in favor of this change.
- Without being able to store the settlement tapleaf hash in the update tx spend, watchtowers will remain as they are today, ie difficult or impossible to operate at scale.
- There is some danger that this opcode could enable some of the less-desirable use cases for OP_CAT.
- My understanding is that the worst of these would be infeasible due to PC not enabling granular introspection.
Acceptable
- Introduced in order to enable LNHANCE to skip having to put the taproot internal key on the stack, saving 32 bytes, the same shortcut used in APO, which LNHANCE is designed to replace.
- Small, easy to reason about, and generally useful.
No
- At first glance, seems small and easy to reason about.
- On second thought, CAT opens up all sorts of cans of worms by enabling granular transaction introspection through abuse of Schnorr signatures and OP_CHECKSIG.
- CAT enables a whole bunch of desirable use cases (poorly) and a whole bunch of undesirable use cases (also poorly).
- Some use cases I consider undesirable:
- On-chain decentralized exchanges (DEXes)
- Automated market makers (AMMs)
- Hashrate escrows (which enable drivechain-like constructions)
- I consider these use cases undesirable because they could make bitcoin much more like Ethereum, in that they potentially cause centralizing MEV and attract the altcoin Ponzi casino into bitcoin’s layer 1, which damages bitcoin’s whole purpose for existing: to be the best money ever devised.
- Using CAT for simple introspection (as in CTV) requires the use of a huge army of CATs and the scripts are ugly and difficult to reason about. (For comparison, using CTV for the exact same use case requires only a single CTV).
- Other covenant upgrades would allow building the most desirable use cases much better than CAT, and would disallow the undesirable ones, so I am not in favor of CAT.
Deficient
- This powerful primitive enables state-carrying contracts, and while it may eventually prove useful, I think it’s too early, especially given that the code is not finalized and there’s no BIP.
Deficient
- Since this opcode enables a lot of the same functionality as CCV, my rationale is the same.
- This opcode has the advantage of being finalized and having a BIP, however.
Deficient
- I see this opcode as a sort of “generalized CTV” where, instead of a single template hash, the developer can choose to commit to any of the fields in a transaction in order to achieve very granular introspection.
- While this is super useful for enabling endogenous fees in L2 protocols (for example), again, as with CCV and VAULT, I don’t think we are ready to have this conversation yet as there are many undesirable use cases such powerful introspection could enable.
- It has the advantage of having a draft BIP.
- It has the disadvantage of making txhash caching much more complex, potentially opening up DoS vectors.
- Given this, it may be a good idea to do Rusty Russell’s Great Script Restoration, which adds a “varops budget”, before or at the same time.
Prefer
- The only non-opcode and the only sighash flag on the list
- Originally proposed as SIGHASH_NOINPUT in the Lightning Network white paper in order to get around transaction malleability.
- Superseded for this use case by segwit.
- Still needed to enable rebindable Symmetry Channels, which, again, are desperately needed in order to scale the Lightning Network.
- Functionality could be replaced by LNHANCE.
- Advantages:
- Has been finalized for years and is generally recognized as safe and desirable.
- Disadvantages:
- Was never intended as a "covenants" upgrade, but indeed enables somewhat awkward covenants.
- Enables “spookchains”, a drivechain-like construction. It seems that people would be unable to build these as they require a trusted setup, but you never know.
- Prefer/Acceptable: I would support activation of CTV, LNHANCE, APO, or any combination of these at the moment.
- No/Deficient: I would not support activation of CAT, CCV, VAULT, or TXHASH at the moment.
Please don't hesitate to reach out to me on Twitter at @cguida6 if you think I got something wrong.