From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "aliashraf.btc At protonmail" <aliashraf.btc@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Sun, 24 Jul 2022 23:40:35 +0000 [thread overview]
Message-ID: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com> (raw)
In-Reply-To: <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
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
next prev parent reply other threads:[~2022-07-24 23:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 20:42 Antoine Riard
2022-07-23 5:09 ` Ryan Grant
2022-07-23 14:57 ` Antoine Riard
2022-07-23 14:25 ` Michael Folkson
2022-07-23 16:41 ` Antoine Riard
2022-07-24 13:01 ` aliashraf.btc At protonmail
2022-07-24 23:40 ` ZmnSCPxj [this message]
2022-07-26 3:20 ` Antoine Riard
2022-07-26 3:18 ` Antoine Riard
2022-07-24 18:22 ` Bram Cohen
2022-07-24 20:26 ` aliashraf.btc At protonmail
2022-07-26 3:21 ` Antoine Riard
2022-07-26 16:02 ` Bram Cohen
2022-08-03 15:37 ` Billy Tetrud
2022-08-09 20:15 ` Antoine Riard
2022-08-27 21:01 ` Billy Tetrud
2022-08-30 15:46 ` Antoine Riard
2022-09-10 0:10 ` Antoine Riard
2022-10-07 15:33 ` Antoine Riard
2022-09-12 0:05 Buck O Perley
2022-09-13 16:02 ` Ryan Grant
2022-09-15 8:05 ` Devrandom
2022-09-16 19:08 ` Antoine Riard
2022-09-16 18:59 ` Antoine Riard
2022-09-17 7:52 ` Devrandom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aliashraf.btc@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox