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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
