Date: Sun, 24 Jul 2022 23:40:35 +0000
To: "aliashraf.btc At protonmail" <aliashraf.btc@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com>
In-Reply-To: <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
 <XSc7hh8TBcrQc8YsYbCj4dmf3YkdQwJAv50lIcAK7rMYH9gChkn_S3SkJFmATwCrD-klYeJ55FajcGQ1HVuY0msxyiah8rLbVlQG7sXkAmo=@protonmail.com>
 <CALZpt+HerfG6hfkPksN=0ih5pRP6m0qAnxH3au7h3gadnHPKdQ@mail.gmail.com>
 <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
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] On a new community process to specify covenants
Precedence: list

Good morning alia, Antoine, and list,

> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in b=
itcoin development, is just too much. Bitcoin development methodology is an=
 open problem, given the contemporary escalation/emergence of challenges, h=
istory is not=C2=A0 entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, but i=
t is not guaranteed that the outcome to be always the same as your take.
>
> I'd suggest instead of inventing a multi-decades-lifecycle based methodol=
ogy (which is weird by itself, let alone installing it as a standard for bi=
tcoin projects), being open-mind=C2=A0 enough for examining more agile appr=
oaches and their inevitable effect on the course of discussions,

A thing I have been mulling is how to prototype such mechanisms more easily=
.

A "reasonably standard" approach was pioneered in Elements Alpha, where an =
entire federated sidechain is created and then used as a testbed for new me=
chanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`.
However, obviously the cost is fairly large, as you need an entire federate=
d sidechain.

It does have the nice advantage that you can use "real" coins, with real va=
lue (subject to the federation being trustworthy, admittedly) in order to c=
onvincingly show a case for real-world use.

As I pointed out in [Smart Contracts Unchained](https://zmnscpxj.github.io/=
bitcoin/unchained.html), an alternative to using a blockchain would be to u=
se federated individual coin outpoints.

A thing I have been pondering is to create a generic contracting platform w=
ith a richer language, which itself is just used to implement a set of `OP_=
` SCRIPT opcodes.
This is similar to my [Microcode proposal](https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2022-March/020158.html) earlier this year.
Thus, it would be possible to prototype new `OP_` codes, or change the beha=
vior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change in b=
ehavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a tran=
slation from `OP_` codes to the richer language.
Then you could prototype a new SCRIPT `OP_` code by providing your own tran=
slation of the new `OP_` code and a SCRIPT that uses that `OP_` code, and u=
sing Smart Contract Unchained to use a real funds outpoint.

Again, we can compare the Bitcoin consensus layer to a form of hardware: ye=
s, we *could* patch it and change it, but that requires a ***LOT*** of work=
 and the new software has to be redeployed by everyone, so it is, practical=
ly speaking, hardware.
Microcode helps this by adding a softer layer without compromising the exis=
ting hard layer.

So... what I have been thinking of is creating some kind of smart contracts=
 unchained platform that allows prototyping new `OP_` codes using a microco=
de mechanism.

Regards,
ZmnSCPxj