Personally, not in particular worried about arbitrary covenants as I think that: 1 validation costs can be kept in check; 2 you're free to burn your coins it you want to.

I *do* care that when we enable covenants we don't make people jump through too many hoops, but I also respect Russel's points that we can enable functionality and then later figure out how to make it more efficient or useful guided by use cases.

However, I think the broader community is unconvinced by the cost benefit of arbitrary covenants. See https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6 as a recent example. Therefore as a critical part of building consensus on various techniques I've worked to emphasize that specific additions do not entail risk of accidentally introducing more than was bargained for to respect the concerns of others.

Well if you're a fan of it, I'm a fan of it, Russel's a fan of it, and Sanket's a fan of it that sounds like a good amount of dev interest :) I know Olaoluwa is also a fan of it too and has some cool L2 protocols using it. 

I think it might not be *hype* because it's been around a while and has always been bundled with cat so been a non starter for the reasons above. I think as an independent non-bundle it's exciting and acceptable to a number of devs. I also believe upgrades can be developed and tracked in parallel so I'm taking on the windmill tilting personally to spearhead that -- on the shoulders of Giants who have been creating specs for this already of course. 

Best,

Jeremy

P.s. icymi https://rubin.io/blog/2021/07/02/covenants/ covers my current thinking about how to proceed w.r.t. deploying and developing covenant systems for bitcoin