rich1.0npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3thttps://nostr.ae/npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3tnjumphttps://nostr.ae📅 Original date posted:2022-02-11 📝 Original message:I don't oppose recursive covenants per se, but in prior posts I have expressed uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script. Not that anyone here is necessarily saying otherwise, but I am very interested in limiting operations in bitcoin script to "verification" (vs. "computation") to the extent practical, and instead encouraging general computation be done off-chain. This of course isn't a new observation and I think the last few years have been very successful to that effect, e.g. the popularity of the "scriptless scripts" idea and Taproot's emphasis on embedding computational artifacts in key tweaks. My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that more logic will live in script than is necessary, and so the burden to verify the chain may grow and the extra "degrees of freedom" in script may make it harder to reason about. But I guess at this point there aren't alternative means to construct new kinds of sighashes that are necessary for some interesting covenants. One thing I like about CTV is that it buys a lot of functionality without increasing the "surface area" of script's design. In general I think there is a lot to be said for this "jets"-style approach[0] of codifying the script operations that you'd actually want to do into single opcodes. This adds functionality while introducing minimal surface area to script, giving script implementers more flexibility for, say, optimization. But of course this comes at the cost of precluding experimentation, and probably requiring more soft-forking. Though whether the place for script experimentation using more general-purpose opcodes on the main chain is another interesting debate... Sorry for going a little off-topic there. [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589 On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev > wrote: > > Whether [recursive covenants] is an issue or not precluding this sort > > of design or not, I defer to others. > > For reference, I believe the last time the merits of allowing recursive > covenants was discussed at length on this list[1], not a single person > replied to say that they were opposed to the idea. > > I would like to suggest that anyone opposed to recursive covenants speak > for themselves (if any intelligent such people exist). Citing the risk > of recursive covenants without presenting a credible argument for the > source of that risk feels to me like (at best) stop energy[2] and (at > worst) FUD. > > -Dave > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html > [2] > http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html > (thanks to AJ who told me about stop energy one time when I was > producing it) > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/bf500325/attachment.html>