>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation.  The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>

I don't think this should be discounted.   I think it's worthwhile to
willingly include possibly less-than-awesome, but proven perfectly-safe
opcodes, knowing we will have to validate them forever, even if new, cooler
and more widely-used ones replace them years from now.

I honestly don't think the development of the latter will happen without
some version of the former.

Personally I am satisfied:

  - the safety of covenants, in general, is covered by how addresses are
generated
  - fears of forced forward-encumbrance are not any worse than can be
easily done today
  - ctv+apo, cat+csfs are fine, but we should pick ones that everyone
thinks are "good enough for everyone who cares about them"
  - they are not an undue burden on nodes in terms of
validate-cpu-cycles-per-byte (have we proven this?)
  - the complexity is low, code is easy to validate
  - won't introduce DDOS attack vectors (also needs to be proven i think?)
  - the game theory underpinning selfish miner support of the chain won't
be altered by causing a widespread use of on-chain leveraging instruments
(shorting bitcoin on-chain would be dangerous, for example)




>