diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2022-07-25 23:18:03 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-26 03:18:17 +0000 |
| commit | 5a34d29a835ee21160da0e152bb4c683ffb006ff (patch) | |
| tree | a044038bda90e795b4e3478ea99a797abfc39f9d | |
| parent | 08bba2a356cb36bf6a6d5299be1a9bcc6fafe2a6 (diff) | |
| download | pi-bitcoindev-5a34d29a835ee21160da0e152bb4c683ffb006ff.tar.gz pi-bitcoindev-5a34d29a835ee21160da0e152bb4c683ffb006ff.zip | |
Re: [bitcoin-dev] On a new community process to specify covenants
| -rw-r--r-- | 39/aee05e8b41198e6b7d396f8dd39ae76a2a5856 | 238 |
1 files changed, 238 insertions, 0 deletions
diff --git a/39/aee05e8b41198e6b7d396f8dd39ae76a2a5856 b/39/aee05e8b41198e6b7d396f8dd39ae76a2a5856 new file mode 100644 index 000000000..8dd9fd31c --- /dev/null +++ b/39/aee05e8b41198e6b7d396f8dd39ae76a2a5856 @@ -0,0 +1,238 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id BCA7DC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2022 03:18:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 8E14F414C1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2022 03:18:17 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8E14F414C1 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=CpeMvV8N +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 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] 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 En0B8xUC_NCI + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2022 03:18:16 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CBF63410A0 +Received: from mail-il1-x130.google.com (mail-il1-x130.google.com + [IPv6:2607:f8b0:4864:20::130]) + by smtp4.osuosl.org (Postfix) with ESMTPS id CBF63410A0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2022 03:18:15 +0000 (UTC) +Received: by mail-il1-x130.google.com with SMTP id u19so6688569ilk.7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Jul 2022 20:18:15 -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=uM3QM6z/tgHIHdDYGx62AhwcnKzN+OoYxiKt5lmNAV0=; + b=CpeMvV8Nbqq6CiFiThswGgs0eS68bwi9FVvFuRdCX6q3UiIcX+sQbORzspWSK4OPEI + mlw4uvkS4Jvkt2xidIgoV194bfqPazdfGOPaW7yijSEZPrX7WNdf2KAfiWtPklBCQEei + S3wyrcPvqHNwBLBju6N7Xh/X4bs7y8Hf50FaXhpajQ5YA341yy96pCL3WRc3UsjBbOz4 + qqu1QMQG2CCSVnI6Piy1msQDZY6rRTmyot+36urX9eFAYi54R4MOK5xz345wDwkQQV6F + vS4Pt/hUc1Y3KWORJ5iUDfEOrRDmIHSkaR7ho01onhoFDwSAuWOBodJAJTO/y79ORsOk + 5X6w== +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=uM3QM6z/tgHIHdDYGx62AhwcnKzN+OoYxiKt5lmNAV0=; + b=8MJhUJRG3PPOV1LhlnCAhVcF30ZaFM32Vw60YuPOYOkgKfQerqueDOulOu94953Tge + JCPFBE38J7dIVG8KvhYHnyL94JSA0Y7x7s4x67jS6PViYRkJZW0LFDzYbie4WvqgLqNS + QzNuxpDOh5QosC7OHEaHIqIBYdDt1zocs1fr2j6TeN8wupuHmKBl0xmK7r3Fj3U0u9Yh + nFJZzPx1Sxs0CldNope9tSvRzGHqf3EnrbMjfM5hKigEdxUVF14DOS4f8bV4Fo3PvOZM + CpBnog9IWTVjQ1mwriT4q3IXJr8Jqe/UxOSNAYFllE51dlcMAmyavPt9G6WD7Zc1KDjn + oNfw== +X-Gm-Message-State: AJIora+YmFILNVBQFSfwI0u+vyaE3Txz0hx1+LMKi62Cllzty6eLu/0Z + hvGGhX/qonY+KA6jhtrKGXNiPNPcghcPwIcYARA= +X-Google-Smtp-Source: AGRyM1ucURqmbdnBo3veoX+EzAxtFFPI0ZfhwU6CccIgYyFQZz8kIXAJXW6/k0qfDxZFCYrlflo/WdATHP/M3BhBp3g= +X-Received: by 2002:a05:6e02:b44:b0:2dd:89bf:6b99 with SMTP id + f4-20020a056e020b4400b002dd89bf6b99mr853971ilu.114.1658805494804; Mon, 25 Jul + 2022 20:18:14 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com> + <XSc7hh8TBcrQc8YsYbCj4dmf3YkdQwJAv50lIcAK7rMYH9gChkn_S3SkJFmATwCrD-klYeJ55FajcGQ1HVuY0msxyiah8rLbVlQG7sXkAmo=@protonmail.com> + <CALZpt+HerfG6hfkPksN=0ih5pRP6m0qAnxH3au7h3gadnHPKdQ@mail.gmail.com> + <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com> +In-Reply-To: <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Mon, 25 Jul 2022 23:18:03 -0400 +Message-ID: <CALZpt+F9OeUij1LzvqK0RkB9Ov6v-it_Jrp4KAXFoOt=OTrmcw@mail.gmail.com> +To: "aliashraf.btc At protonmail" <aliashraf.btc@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000044f9d505e4acc023" +X-Mailman-Approved-At: Tue, 26 Jul 2022 08:20:21 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 26 Jul 2022 03:18:17 -0000 + +--00000000000044f9d505e4acc023 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi aliashraf, + +Well, reading the excerpt you're pointing to, I'm using the term "high +standard" and deliberately not best practice. I hope with the increase in +the funds at stakes in the ecosystem and the growth in the technical +complexity, we'll set higher and higher standards in terms of Bitcoin +development. For sure, I think engineering standards are not a thing to be +encoded in a history book and we rest as "done". Rather more as a living +matter, with the same type of reasoning practiced in common law based on +cases or civil engineering based on disasters. + +About a multi-decades-lifecycle based methodology, not in the domain of +consensus changes, but in terms of Core policy, I think I've always +advocated for more documentation and communication towards the community +[0]. However, it should be noted that any additional engineering process we +hold as standard is to be enforced by a set of FOSS contributors, of which +the time and energy is limited. So I think it's better to advance in an +evolutionary and consensus-driven way, and hopefully avoid regression. + +That said, if you have concrete examples of good engineering practices we +could adopt in Bitcoin development, especially w.r.t consensus changes, I'm +curious about it. + +[0] https://github.com/bitcoin/bitcoin/issues/22806 + +Le dim. 24 juil. 2022 =C3=A0 09:01, aliashraf.btc At protonmail < +aliashraf.btc@protonmail.com> a =C3=A9crit : + +> ------- Original Message ------- +> On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> Hi Michael, +> +> +> I'm thinking such a covenant effort would be more a technical process +> aiming to advance the state of covenant & contracting knowledge, collect +> and document the use-cases, exchange engineering learnings from the +> prototype, share the problem space, etc. In the same fashion we have the +> BOLT one or even more remote the IETF working groups about a bunch of +> Internet technology [0]. I think that Taproot/Schnorr has set a high +> standard in terms of safety-first and careful Bitcoin engineering effort, +> aggregating 8 years of thinking around MAST and friends but also explorin= +g +> other signature schemes like BLS. And I hope with covenants we aim for +> higher standards, as if there is one learning from Taproot we could have +> spent more time working out use-cases prototypes (e.g joinpools) and +> standard libraries to mature, it could have save actual headache around +> x-pubkeys [1] +> +> 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 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 +> 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= +, +> +> Cheers, +> +> +> + +--00000000000044f9d505e4acc023 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi aliashraf,<br><br>Well, reading the excerpt you're = +pointing to, I'm using the term "high standard" and deliberat= +ely not best practice. I hope with the increase in the funds at stakes in t= +he ecosystem and the growth in the technical complexity, we'll set high= +er and higher standards in terms of Bitcoin development. For sure, I think = +engineering standards are not a thing to be encoded in a history book and w= +e rest as "done". Rather more as a living matter, with the same t= +ype of reasoning practiced in common law based on cases or civil engineerin= +g based on disasters.<br><br>About a multi-decades-lifecycle based methodol= +ogy, not in the domain of consensus changes, but in terms of Core policy, I= + think I've always advocated for more documentation and communication t= +owards the community [0]. However, it should be noted that any additional e= +ngineering process we hold as standard is to be enforced by a set of FOSS c= +ontributors, of which the time and energy is limited. So I think it's b= +etter to advance in an evolutionary and consensus-driven way, and hopefully= + avoid regression.<br><br>That said, if you have concrete examples of good = +engineering practices we could adopt in Bitcoin development, especially w.r= +.t consensus changes, I'm curious about it.<br><br>[0] <a href=3D"https= +://github.com/bitcoin/bitcoin/issues/22806">https://github.com/bitcoin/bitc= +oin/issues/22806</a><br></div><br><div class=3D"gmail_quote"><div dir=3D"lt= +r" class=3D"gmail_attr">Le=C2=A0dim. 24 juil. 2022 =C3=A0=C2=A009:01, alias= +hraf.btc At protonmail <<a href=3D"mailto:aliashraf.btc@protonmail.com">= +aliashraf.btc@protonmail.com</a>> a =C3=A9crit=C2=A0:<br></div><blockquo= +te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = +solid rgb(204,204,204);padding-left:1ex"><div><span style=3D"font-family:Ar= +ial">------- Original Message -------</span><div> + On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via +bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta= +rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br= +> + <blockquote type=3D"cite"> + <div dir=3D"ltr">Hi Michael,<div><br></div><br><div>I'm +thinking such a covenant effort would be more a technical process aiming + to advance the state of covenant & contracting knowledge, collect +and document the use-cases, exchange engineering learnings from the +prototype, share the problem space, etc. In the same fashion we have the + BOLT one or even more remote the IETF working groups about a bunch of +Internet technology [0]. I think that Taproot/Schnorr has set a high +standard in terms of safety-first and careful Bitcoin engineering +effort, aggregating 8 years of thinking around MAST and friends but also + exploring other signature schemes like BLS. And I hope with covenants +we aim for higher standards, as if there is one learning from Taproot we + could have spent more time working out use-cases prototypes (e.g +joinpools) and standard libraries to mature, it could have save actual +headache around x-pubkeys [1] </div><br> + </div></blockquote></div></div><div style=3D"font-family:Arial;font-siz= +e:14px;color:rgb(0,0,0)">Hi Antoine, <br></div><div>Claiming Taproot histor= +y, as best practice or a standard methodology in bitcoin development, is ju= +st too much. Bitcoin development methodology is an open problem, given the = +contemporary escalation/emergence of challenges, history is not=C2=A0 entit= +led to be hard coded as standard.</div><div><br></div><div style=3D"font-fa= +mily:Arial;font-size:14px;color:rgb(0,0,0)">Schnorr/MAST development histor= +y, is a good subject for case study, but it is not guaranteed that the outc= +ome to be always the same as your take. <br></div><div style=3D"font-family= +:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"font-family= +:Arial;font-size:14px;color:rgb(0,0,0)">I'd suggest instead of inventin= +g a multi-decades-lifecycle based methodology (which is weird by itself, le= +t alone installing it as a standard for bitcoin projects), being open-mind= +=C2=A0 enough for examining more agile approaches and their inevitable effe= +ct on the course of discussions, <br></div><div style=3D"font-family:Arial;= +font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"font-family:Arial;= +font-size:14px;color:rgb(0,0,0)">Cheers,<br></div><div style=3D"font-family= +:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div><br></div></blockquo= +te></div> + +--00000000000044f9d505e4acc023-- + |