Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9544BC002D for ; Tue, 26 Jul 2022 03:20:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6FCD540439 for ; Tue, 26 Jul 2022 03:20:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6FCD540439 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=YsM8RJqT X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTZ3nVMD_h6h for ; Tue, 26 Jul 2022 03:20:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E24E44015A Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) by smtp2.osuosl.org (Postfix) with ESMTPS id E24E44015A for ; Tue, 26 Jul 2022 03:20:43 +0000 (UTC) Received: by mail-il1-x131.google.com with SMTP id d4so6683185ilc.8 for ; Mon, 25 Jul 2022 20:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qb8P1DYilWN3aM4ZipI74Jx3JHpXuJoT2vzZudKjt88=; b=YsM8RJqT8X4x8l3HZYjuvPhOXZaJWDCGk3IXxWz55y9JkW1WuX63a2YE0Y6RuoqccK FUrl/JfVhbndnpK4GLUeqEV1g2oVuofhOqoQMFJeQwI77tX2MHd8FYluqipdQZO6TP1N xOR1UPUP4i6ymGYJG+UmfKEKVCF58YzUfBp2QWFgBbs6nD7fZJjAD0rKMGrZJOfpj/w9 awSIFgWhLT91TibvWXEqy1uqp7qVLitFEZGfEx4YgKbt6U/A5mycP0JqD4kGomaTv7/o BYywlsk18KPVgKC1+kd3cMqpCMvJvmvWApLSrmmUSSe2fuA6oxE9W+xi0cuL91TB6yPl DHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qb8P1DYilWN3aM4ZipI74Jx3JHpXuJoT2vzZudKjt88=; b=RjBFpMm8zlEzYX+J+i0aLQfpJq35iUiWMXizqrNrRSsIvok3DgOrwmfC+6buN7gNS/ eGyYZY3OC++sETBRMOB9MJE0oHBE0NvQNQy+4YtaTmrpx+md5DFs/YDjYzqUAJRlDUl1 GnfC1QHXOSpioiROF/Im5GHbrQV21YlN0IzTzHphl1cAXVvmL5ZuWEvpnEWfdFZxThof +uiJL3q+mrQE7COCUQozsqrGStmjNx07aDNS3+r/DNXOL98e/kT0456PjR56u6ptT9ao WJvUeVxRqJNrbwSKNZs+/k7T4fZtxFAbNCirvtDpzcj4sLEDBHnWlLsrcy8hg37Sv3Ap Hv0Q== X-Gm-Message-State: AJIora/mv3SxPM3LQwtw7l0m3bFFSkGyeLx5ZuKMFbDwEvPzO9Mtqvcw iR9xIhjdy/WnH/yNY9ZeBXLyQEnWzVY5/zuv8jVEED7ED4w= X-Google-Smtp-Source: AGRyM1v9x0YTH3NWY41Ynh47B2RGeVecAXkl3RBbERfgzBxYKT7eJPV0cfAT8mq9VbzQ5NJwd3ZXnUpUAjkzeEYpK3A= X-Received: by 2002:a92:6603:0:b0:2da:82b6:34a3 with SMTP id a3-20020a926603000000b002da82b634a3mr5809140ilc.250.1658805642923; Mon, 25 Jul 2022 20:20:42 -0700 (PDT) MIME-Version: 1.0 References: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com> In-Reply-To: <0tp0SQgSX6kVG84bQ6fk7umnv3IaC2Nx6leiGYxhayz2HCQymAuBJxaODFijqLPP0nJ1b41wE4wlC-0_H8eN2GadtVEqGBGWGlzuMtfjhDo=@protonmail.com> From: Antoine Riard Date: Mon, 25 Jul 2022 23:20:31 -0400 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000001911e105e4acc9db" X-Mailman-Approved-At: Tue, 26 Jul 2022 08:20:21 +0000 Cc: Bitcoin Protocol Discussion 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: Tue, 26 Jul 2022 03:20:45 -0000 --0000000000001911e105e4acc9db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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/002= 884.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.ht= ml Le dim. 24 juil. 2022 =C3=A0 19:40, ZmnSCPxj a = =C3=A9crit : > 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 challenge= s, > 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 mor= e > 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 a= n > 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 chang= e > 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 usin= g > a microcode mechanism. > > Regards, > ZmnSCPxj > --0000000000001911e105e4acc9db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Zeeman,

So on the first concern of using an &quo= t;economic simulation" or sidechains/other cryptocurrencies to gather = feedback about interest of Script extensions, I wonder about the value tran= sitivity 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 prefer= red in system B, unless I think you have the same agent. However, in crypto= currencies, 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 t= he future if we have a privacy-preserving coins ownership proof system we c= ould 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-o= ffs analysis and adequate covenant designs grounds.

Activation reall= y should be its own dedicated process, well-splitted in terms of communicat= ion 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 le= ast three caveats in my opinion 1) we might open a Pandora Box enabling one= to design trustless bribing contracts towards miners to attack existent de= ployed Bitcoin use-cases like Lightning (not a theoretical concern at all w= hen we look on the wild west of Defi in other cryptocurrencies) 2) the mult= i-party contract protocol problem space is relatively early, we might evolv= e the primitive abstraction with which we're dealing and the language i= tself should evolve 3) we might still have to do a lot of economic engineer= ing if the microcode operations or syntax units of the language are boundin= g well to validation nodes ressources.

So IMHO, a lot of unknowns ab= out a generic contracting platform (even if it's tempting from an appli= cation 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.or= g/pipermail/bitcoin-dev/2021-July/019243.html

Le=C2=A0dim. 24 juil= . 2022 =C3=A0=C2=A019:40, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=A9crit=C2=A0:
Good morning alia, Antoine, and = list,

> Hi Antoine,
> Claiming Taproot history, as best practice or a standard methodology i= n bitcoin development, is just too much. Bitcoin development methodology is= an open problem, given the contemporary escalation/emergence of challenges= , history is not=C2=A0 entitled to be hard coded as standard.
>
> Schnorr/MAST development history, is a good subject for case study, bu= t 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 m= ethodology (which is weird by itself, let alone installing it as a standard= for bitcoin projects), being open-mind=C2=A0 enough for examining more agi= le 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 federate= d sidechain.

It does have the nice advantage that you can use "real" coins, wi= th 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](htt= ps://zmnscpxj.github.io/bitcoin/unchained.html), an alternative to usin= g a blockchain would be to use 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.org/pipermail/bitcoin-de= v/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
--0000000000001911e105e4acc9db--