Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 72485C002D for ; Sun, 24 Jul 2022 23:40:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 369FA41881 for ; Sun, 24 Jul 2022 23:40:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 369FA41881 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=rAkeV+zm X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8DBHHtwjkvO for ; Sun, 24 Jul 2022 23:40:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A16E41768 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9A16E41768 for ; Sun, 24 Jul 2022 23:40:43 +0000 (UTC) Date: Sun, 24 Jul 2022 23:40:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1658706041; x=1658965241; bh=euEUvNgx6lxCxKBVEgZTIqv1lQcfD5zYt/5PaPZnKSo=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=rAkeV+zmLh6WKDpAAuAXU9av9YfMSW0BL3C+dAMvrsfv+EoktD5ofrfBXgxMVoVGr vLiGpbDn3PMH9/PvhYI4fesUTK+FLtGv/bYrFKjtlemLXVhU9isgnrVEiKwjzPJt1+ 8P46vPt3mk9u3lCptAMK/YiufN7TfH/58sD3VfwzrSeQBTDBY++yeNzeePV7V4NW4j qtBM7/xfZAmKPaazYZwYIl/32woDk7HP0cZfHw85xPpDLwVCI4SKUps9XoUcOA7gpN lpPnFfXn/tEWYB8QRulYQUIZMB0SQVjhnraWa26ETUM0op3c+VuXkbO51o/v5mX6VO WIJ+D+CthWbEQ== To: "aliashraf.btc At protonmail" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com> In-Reply-To: References: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2022 23:40:45 -0000 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