Author: Anthony Towns 2022-03-04 01:04:42
Published on: 2022-03-04T01:04:42+00:00
The bitcoin-dev mailing list is currently discussing the possibility of generalizing the OP_EVICT opcode and breaking it down into smaller parts. Some developers suggest using a Lisp-like language that would treat code and data exactly the same. They believe chia lisp gets most of the design decisions right, but it would need some changes to support secp256k1 signatures and tx introspection instead of bundle-oriented CREATE_COIN and CREATE/ASSERT results.To match Bitcoin Script and chia lisp, the author suggests creating around 40 opcodes, such as q (quote), a (apply), x (exception/immediately fail), i (if/then/else), not, all, any (boolean logic), and sha256 (hashing). Using a Lisp-style approach would simplify certain functions and improve performance.The author of this email suggests that chia lisp may be a better solution to the problem than Simplicity language due to its fewer opcodes, feasible approaches to low-impact soft forks, and only two levels of abstraction. They suggest incorporating great new ideas from altcoins into Bitcoin with chia lisp and define two approaches to upgradability: defining a new version of the language via the tapleaf version or using the "softfork" opcode.The author also discusses some issues with maintaining the mempool and using that to speed up block acceptance, as the chia chain has apparently suffered from mempool-flooding attacks recently. The author thinks it still makes more sense to stick with bitcoin's current model here.
Updated on: 2023-05-22T17:49:42.315832+00:00