Author: ZmnSCPxj 2022-03-04 23:10:48
Published on: 2022-03-04T23:10:48+00:00
The email thread discusses possible generalizations of the `OP_EVICT` opcode in Bitcoin script. The idea is to decompose it into smaller parts, including an operation congruent to the Scheme/Haskell/Scala `map` operation. The author endorses LISP as a language, combining it with the idea of committing to a maximum number of operations, which increases the weight of the transaction, and making any `eval` implementation within the same language total. However, LISP has scalability issues due to its code and data being homoiconic to each other, which makes communication between programmers difficult at scale. The email thread also discusses upgradability in Bitcoin script. One approach is to define a new version of the language via the tapleaf version, defining new opcodes however desired. Another approach is to use the "softfork" opcode, which behaves more like OP_NOP than tapscript's OP_SUCCESS. The softfork enables the opcode for a block of code, but the entire block of code returns zero. The `softfork` form would have to be a syntax rather than a procedure since it requires static determination of cost and version.
Updated on: 2023-06-15T17:32:37.901118+00:00