Hawk-eye

Observations from the covenants support wiki

I had created the first draft for a bitcoin wiki page to gather evaluations from developers on different soft fork proposals and link was shared on mailing list. 32 developers have shared their opinion until now.

OP_CHECKCONTRACTVERIFY

No developers have objections with OP_CCV but its reviewed by very less developers. There could be multiple reasons for it, however this is the first thing that I noticed in the table.

OP_PAIRCOMMIT

5 developers have objections with this opcode and its also less reviewed. This opcode is a combination of OP_CAT, OP_SHA256 and part of LNHANCE proposal.

OP_CHECKSIGFROMSTACK

It has the highest support in the table from all developers. Nobody wants to activate it alone but its a part of some proposals with other opcodes.

OP_INTERNALKEY

This seems to be a simple opcode that could save 32 bytes and part of LNHANCE proposal. However, 4 developers have some objections with it. Luke Dashjr had shared the reasons in a telegram group and on twitter. Rearden had responded to the concerns and its possible that re-evaluations would change this column.

OP_CAT

This seems to be a controversial opcode in the community hence you see multiple developers using ‘deficient’ option for it. Some developers have also marked ‘no’ and do not want OP_CAT because it enables too many things.

SIGHASH_ANYPREVOUT

This is another proposal with interesting evaluations in the table because it was perceived to have enough support in the community. With more rationales added in the table, it could become clear why developers do not prefer it anymore.

OP_VAULT, OP_TXHASH

These 2 opcodes have mixed opinions and we will need rationale added in the last column by all developers to understand the reasons for this evaluation.

OP_CHECKTEMPLATEVERIFY

3 developers have objections with this opcode and 2 of them belong to Zerosync. The bias is easy to understand if you go through the tweets of Robin Linus. None of them have added a rationale yet so we can only assume the reasons for it.

Conclusion

This table has made it easier to analyze the opinion of different bitcoin developers on proposed soft forks. There is always room for improvement, however the primary goal to reach some technical consensus could be achieved with it and followed by further discussion on mailing list.

https://groups.google.com/g/bitcoindev/c/QOnpM4Ixmms/m/8m1_l5RSDAAJ