Date: Mon, 25 Apr 2022 05:12:10 +0000
To: "David A. Harding" <dave@dtrt.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <UWxdkhOFe4dSFiV8z5uYiAySZSj-YDfH6vG3nasOSrqiZg9W1gDfmNc1MbSNTtJV6fr2j_Ch9AkpbpJWflY8cUfsBT08B3XXYVht8zptF_4=@protonmail.com>
In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
	e.g. for CTV
Precedence: list

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 ac=
tual users demand".

An idea that has been percolating in my various computation systems is to u=
se 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 gener=
al 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 / beha=
vior) 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 m=
icrocode, and instead of sending funds to a new version of the Bitcoin SCRI=
PT 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 re=
quiring 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 Bitc=
oin Core, so that the mechanics of merging in a new opcode, that was protot=
yped 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 correspondi=
ng micro-opcodes and runs that, possibly with reasonable limits on executio=
n 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 s=
upposed 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 interpret=
ers 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