> > > > 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) >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
