Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Dave, et al.,

I have not read through *all* the mail on this thread, but have read a fair amount of it.

I think the main argument *for* this particular idea is that "it allows the use of real-world non-toy funds to prove that this feature is something actual users demand".

An idea that has been percolating in my various computation systems is to use Smart Contracts Unchained to implement a variant of the Microcode idea I put forth some months ago.

Briefly, define a set of "more detailed" opcodes that would allow any general computation to be performed.
This is the micro-opcode instruction set.

Then, when a new opcode or behavior is proposed for Bitcoin SCRIPT, create a new mapping from Bitcoin SCRIPT opcodes (including the new opcodes / behavior) to the micro-opcodes.
This is a microcode.

Then use Smart Contracts Unchained.
This means that we commit to the microcode, plus the SCRIPT that uses the microcode, and instead of sending funds to a new version of the Bitcoin SCRIPT that uses the new opcode(s), send to a "(n-of-n of users) or (1-of-users and (k-of-n of federation))".

This is no worse security-wise than using a federated sidechain, without requiring a complete sidechain implementation, and allows the same code (the micro-opcode interpreter) to be reused across all ideas.
It may even be worthwhile to include the micro-opcode interpreter into Bitcoin Core, so that the mechanics of merging in a new opcode, that was prototyped via this mechanism, is easier.

The federation only needs to interpret the micro-opcode instruction set; it simply translates the (modified) Bitcoin SCRIPT opcodes to the corresponding micro-opcodes and runs that, possibly with reasonable limits on execution time.
Users are not required to trust a particular fixed set of k-of-n federation, but may choose any k-of-n they believe is trustworthy.

This idea does not require consensus at any point in time.
It allows "real" funds to be used, thus demonstrating real demand for the supposed innovation.
The problem is the effective erosion of security to depending on k-of-n of a federation.

Presumably, proponents of a new opcode or feature would run a micro-opcode interpreter faithfully, so that users have a positive experience with their new opcode, and would carefully monitor and vet the micro-opcode interpreters run by other supposed proponents, on the assumption that a sub-goal of such proponents would be to encourage use of the new opcode / feature.

Regards,
ZmnSCPxj