Author: James O'Beirne 2022-02-11 17:42:11
Published on: 2022-02-11T17:42:11+00:00
The author of the post expresses uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script. They are interested in limiting operations in bitcoin script to "verification" (vs. "computation") to the extent practical, and instead encouraging general computation be done off-chain. The author's worry about opcodes like OP_CAT and OP_TX is that more logic will live in script than is necessary, making it harder to reason about. However, the popularity of the "scriptless scripts" idea and Taproot's emphasis on embedding computational artifacts in key tweaks have successfully encouraged general computation off-chain. The author likes the idea of CTV as it buys a lot of functionality without increasing the "surface area" of script's design. In general, they think there is a lot to be said for the "jets"-style approach 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 optimization. However, this comes at the cost of precluding experimentation and probably requiring more soft-forking. In response to the post, David A. Harding suggests that anyone opposed to recursive covenants should speak for themselves and present a credible argument for the source of that risk. He cites a previous discussion on the merits of allowing recursive covenants where not a single person replied to say that they were opposed to the idea. The author of the post did not express opposition to recursive covenants per se but rather expressed uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script.
Updated on: 2023-06-15T16:39:07.107027+00:00