Author: Antoine Riard 2022-07-26 03:20:31
Published on: 2022-07-26T03:20:31+00:00
In a recent email exchange, the writer raises concerns about using an "economic simulation" or sidechains/other cryptocurrencies to gather feedback about interest of script extensions and the value transitivity of such a process to measure consensus. They argue that direct assets in system B should be used to express preferences instead. However, they also note the importance of having trust-minimized data signals for community decision-making. The writer proposes a covenant working group/process that focuses on use-cases collection, deep trade-offs analysis, and adequate covenant designs. They suggest that activation should be its own dedicated process with separate communication channels, documentation archives, and timeframes. Regarding a generic contracting platform approach, the writer sees it as a gain in flexibility for multi-party contract protocols design but identifies at least three caveats: enabling trustless bribing contracts towards miners to attack existent deployed Bitcoin use-cases like Lightning, still evolving primitive abstractions, and requiring economic engineering if the microcode operations or syntax units of the language are bounding well to validation nodes resources. The writer suggests creating a smart contracts unchained platform that allows prototyping new `OP_` codes using a microcode mechanism. This would help add a softer layer without compromising the existing hard layer of the Bitcoin consensus layer. The proposal involves creating a generic contracting platform with a richer language that is used to implement a set of `OP_` SCRIPT opcodes, similar to their earlier Microcode proposal. By having a translation from `OP_` codes to the richer language, it would be possible to prototype new `OP_` codes or change the behavior of existing ones.
Updated on: 2023-06-15T23:04:43.671448+00:00