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