Author: Anthony Towns 2022-03-22 23:11:05
Published on: 2022-03-22T23:11:05+00:00
A proposal for microcode for Bitcoin SCRIPT has been made. The proposal includes defining a generic low-level language, RISC, and then mapping it to a specific high-level language. Users can sacrifice Bitcoins to define new microcodes. The proposed RISC language includes general instructions such as arithmetic, SECP256K1 scalar and point math, bytevector concatenation, sha256 midstates, bytevector bit manipulation, transaction introspection, and so on. The defined microcode is compiled using LLVM and then stored in a 256-long array of functions, where the array index is the `OP_` code. Bugs in existing microcodes can be fixed by basing a new microcode from the existing microcode and redefining the buggy implementation. Existing Tapscripts need to be re-spent to point to the new bugfixed microcode, but if you used the point-spend branch as an N-of-N of all participants you have an upgrade mechanism for free. There are concerns about the cost of introducing new functionality and the storage size of the "microcode-utxo" database. Additionally, there is a tragedy-of-the-commons problem wherein whoever creates the microcode pays the cost, but anyone can use it and gain the benefit, which could create centralization pressure. This approach isn't very composable, and it might be good to explain how this proposal addresses the concerns raised at the end of a previous discussion on recursive covenants.
Updated on: 2023-05-22T18:30:33.986281+00:00