Examining ScriptPubkeys in Bitcoin Script

The email discusses two reasons for considering a specific approach in programming. The first reason is to perform vault operations effectively, which requires a balance between easy implementation and use. The second reason is to make bitcoin more programmable, allowing for contracting experiments directly in wallet software without the need for new soft forks for each experiment. This approach provides a good balance between opening up a wide range of experiments, understanding their scope and consequences, and being easy to implement and use.

The author expresses skepticism about the proposed approach for vault operations due to its complexity and difficulty of use compared to the OP_VAULT proposal. They believe that the proposed approach does not work well even after significant effort to make it functional. However, in the context of enabling experimentation more generally, the approach becomes more interesting. It allows for various constraints on signatures and the inclusion of authenticated data in a script.

The author suggests that using a Lisp variant would be a promising solution to enhance the programming language. By replacing script's "two stacks of byte-strings" with "(recursive) lists of byte-strings," the language can become more complete. They have been experimenting with this idea and believe that a fairly effective language can be created with around 43 opcodes. Additionally, they propose an example of adding an OP_TX opcode to select information about a transaction, allowing for the experimentation of new SIGHASH modes.

The author acknowledges that the example provided is not easy to read, as it resembles programming in assembler. They mention the need for a higher-level macro-enabled Lisp variation or a parser that allows for comments. The current implementation is an eager interpreter with some tail call optimizations, but they suggest that a properly lazy interpreter would be better for memory efficiency. They also mention other potential improvements such as encoding/decoding lists as a byte stream, providing additional crypto operations, and handling exceptions and allocations.

In conclusion, the author believes that the proposed approach offers a more promising solution for experimentation compared to trying to fit everything into the limitations of script. They find that a Lisp-like language with OP_TX, OP_CAT, OP_CSFS, and other opcodes can work effectively for various use cases.