Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-14 📝 Original message:> > > > FWIW, I think the ...

📅 Original date posted:2022-05-14
📝 Original message:>
>
>
> 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)




>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220514/4d21bc38/attachment.html>;