pull down to refresh

This is a transcript of my X post

I've put the Covenants Support Table into numbers once again.

With an activation client for LNhance just around the corner and consensus forming on the need for more expresivity in Bitcoin Script, I've decided to up the put the Covenants Support Table into numbers once again, this time you will find a Google Sheet to copy and play with and comment if you find anything wrong with it.
Disclaimer: This summary is just a way for you to have an idea on what is going on, not an ultimate answer as to if there's consensus or not since consensus can't be put into numbers alone, there are a lot of politics involved into this process and that can't be accounted for in numbers, only rationales, incentives and interests by all parties can account for the cost of politics in the process of making consensus, opinions expressed here are my own interpretation of what's going on.
Again we are using the same system as before, but this time there are 3 sections for all of it: All, With Rationale, Without Rationale. I will be evaluating All but you'll get a link to all tables at the end so you can draw your own extended conclusions.
For those who don't want to read the previous post here's a summary of how simple the point system is:
Prefer +3 Acceptable +2 Wanting +1 Weak 0 Deficient -1 No -3 Evaluating 0
The max points a single op_code can get is 156 an the minimum it can get is -156 meaning that a score of 78 or more means that there's positive consensus around it while at score of -78 or less means there's negative consensus around it, anything inside a range of 78 to -78 can be regarded as leaning to one side or another of the consensus, again, this is a system I made up myself, there are a lot more intricacies to this .
You'd be surprised as how positive things are looking for CAT. Last time I took the time to review the whole table the order of most liked things was: CSFS in the first place, CTV second and CAT third, not things has inverted for CTV and CAT and CAT is the second most liked OP_Code while still being more controversial than CTV, CAT has more negative reviews, but they are less harsh than the negative reviews for CTV.
So lets evaluate them one by one in the order they are presented in the table:
CTV (66) is still the second most controversial covenant proposal, not good enough on its own but very powerful when used with other op_codes, it's main impediment is that TXHASH exists which is way more powerful, you'll find that more often than not, the main reason to go against CTV is to support TXHASH and vise versa.
CSFS (91) is still the king with absolutely no negative reviews, the worst it gets is 2 "Weak" which are valued at 0 and a few "Evaluating" here and there, also valued at 0, the reason everyone likes it is because when paired with CTV (or TXHASH) it allows for LN-Symmetry.
PairCommit (-6) is still the least liked op_code and he least evaluated as it on it's own is just CAT with extra steps (as far as I understand), but a great optimization for LNhance according to the team behind it, I can't comment on this as the possibilities of each op_code are not just beyond the scope of this post but way above my pay-grade, I'm just a techie who's very interested in this conversation, not an engineer who understand the full scope of every single thing.
InternalKey (39) is in the same place as PairCommit when it comes to interest, it's a nice addition to LNhance because it saves bytes but nobody is paying too much attention to it, although it has way more positive consensus than other op_codes of the list that if you've been paying attention, would be surprised they are not as positive as you would thought.
CAT (80) is still as controversial as ever, but with more positive consensus around it than CTV, those whole like CAT seem to also like either CTV or TXHASH, in both cases +CSFS.
CCV (14) not as positive as one might think, in this case I believe it's because there's more consensus around emulating it with a combination of op_codes that allow for a broader design space than to enable it on its own, it's the same reason many might prefer CAT over CTV as CAT allows to emulate CTV, in a very clumsy way.
Vault (8) this one was a certainly a surprise, the main reason for many to activate any kind of covenants is to get some kind of vaults, so why doesn't op_vault has more positive consensus? Same reason as CCV, can be emulated by other combinantions of op_codes which could lead to more powerful vaults that what op_vault allows on its own.
TXHASH (56) very controversial but not as studied as CTV, the main reason to like it is because it is just CTV Pro Max (literally), which is as well the main reason to dislike it, everyone seem to like the functionality but no everyone believe that we are ready for it yet.
APO (4) it's not an op_code but a sighash, allows for LN-Symmetry but it's not very efficient at it, that's why most developers rather have CTV+CSFS than APO.
After this the next logical step would be to evalutate LNhance itself, there are two sub categories here, first we have half LNhance (CTV+CSFS) and whole LNhance (CTV+CSFS+PC+IKEY), lets do it in that order.
Half LNhance (157) it's just the combination a 2 op_codes, together they allow for things such as LN-Symmetry, Timeout Trees, Coordinatorless Coinjoins, etc... following the same system, a score of 312 would be the max it can achieve while a score of -312 would mean it's the most negative it can get, 156 would grant it positive consensus, this combination of op_codes together get a total score of 157, just above the chasm of eternal notgoodenoughness, it's a combination everybody likes, and those who don't like it, like in a different matter (I'm looking at you people who like TXHASH but not CTV).
Whole LNhance (190) it's just the same as before but with some optimizations, while not as positive as half LNhance, it's still very positive for how unstudied the optimizations are, I believe the view on whole LNhance will change once an activation client is released and people get up to speed with it, for whole LNhance to achieve positive consensus it would need to find a score of 312, but it just goes over the half of that score, lets see what happens when it goes under absolute scrutiny.
Here you have a link to the Google Sheet I've been using to draw this comparison: Covenant support scoreboard
You can join as a commentator and add anything you like to it, if you want to edit it, just contact me as I would love to find people who want to collaborate here, it'd be great to have this updated with better formulas, etc... So anyone can check it at any time and find it easy to understand.
10 sats \ 1 reply \ @ChrisS 7 Jan
This is a great project and I enjoy reading your posts and spreadsheets.
consensus forming on the need for more expresivity in Bitcoin Script.
I'm interested in learning more about why you seem sure this consensus is forming and amongst whom it is forming. Keep up the good work.
reply
Hey thanks for the comment!
What makes me believe consensus is forming about this is being part of the conversation, not that many people are paying attention to it, since most believe "Bitcoin is unchangeable" so why care about it?
The reason this conversation is happening right now is because most developers I know want LN-Symmetry and other features to help scale Bitcoin off-chain, we already know that Lightning in the state it is today is not enough to scale Bitcoin as it doesn't scale ownership, you can't simply create a Lightning wallet and send money to your grandma as you can on-chain, it all depends of a lot of many factors such as liquidity, on-chain fees, etc... Covenants allow us to remove those limitations by having a lot more design space, they also keep the chain from getting impossibly expensive to use for most folks if we get these things via BitVM or other hacky ways, so yeah, I believe consensus is forming that this might be a need while we are all still against a block size increase.
That one will come with quantum-resistant signatures surely, but not before, before that we need better ways to do the stuff needed to scale Bitcoin.
reply