Hi Zeeman,

So on the first concern of using an "economic simulation" or sidechains/other cryptocurrencies to gather feedback about interest of Script extensions, I wonder about the value transitivity of such a process to measure consensus. Namely, if you have asset X picked up in system A, it doesn't tell you the same asset X is preferred in system B, unless I think you have the same agent. However, in cryptocurrencies, at least in Bitcoin, we assume pseudonymous participants. So it can be really hard to say it's the same agent to qualify its utility. Of course, you could have some linking between system A and system B, like signatures if the same signing scheme is used. However if it's possible why not use direct assets in system B to express a preference ? Maybe in the future if we have a privacy-preserving coins ownership proof system we could use that as one consensus indicator [0] ?

At least in terms of community decision-making, the more we have trust-minimized data signals, _assuming_ we have the information capabilities to process them, the better we're.

That said, about the covenant working group/process I'm proposing I would like to stay on the use-cases collection, deep trade-offs analysis and adequate covenant designs grounds.

Activation really should be its own dedicated process, well-splitted in terms of communication channels, documentation archive and timeframes.

About a generic contracting platform approach, I think for sure it would be a huge gain in flexibility for multi-party contract protocols design though there is at least three caveats in my opinion 1) we might open a Pandora Box enabling one to design trustless bribing contracts towards miners to attack existent deployed Bitcoin use-cases like Lightning (not a theoretical concern at all when we look on the wild west of Defi in other cryptocurrencies) 2) the multi-party contract protocol problem space is relatively early, we might evolve the primitive abstraction with which we're dealing and the language itself should evolve 3) we might still have to do a lot of economic engineering if the microcode operations or syntax units of the language are bounding well to validation nodes ressources.

So IMHO, a lot of unknowns about a generic contracting platform (even if it's tempting from an application developer viewpoint I know)

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
[1] For example an input-output bundle abstraction might be better for fee-bumping reasons:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html

Le dim. 24 juil. 2022 à 19:40, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :
Good morning alia, Antoine, and list,

> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not  entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, but it 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 methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind  enough for examining more agile approaches 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 mechanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`.
However, obviously the cost is fairly large, as you need an entire federated sidechain.

It does have the nice advantage that you can use "real" coins, with real value (subject to the federation being trustworthy, admittedly) in order to convincingly 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 use federated individual coin outpoints.

A thing I have been pondering is to create a generic contracting platform with 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.org/pipermail/bitcoin-dev/2022-March/020158.html) earlier this year.
Thus, it would be possible to prototype new `OP_` codes, or change the behavior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change in behavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a translation from `OP_` codes to the richer language.
Then you could prototype a new SCRIPT `OP_` code by providing your own translation of the new `OP_` code and a SCRIPT that uses that `OP_` code, and using Smart Contract Unchained to use a real funds outpoint.

Again, we can compare the Bitcoin consensus layer to a form of hardware: yes, 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, practically speaking, hardware.
Microcode helps this by adding a softer layer without compromising the existing 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 microcode mechanism.

Regards,
ZmnSCPxj