path: root/39/aee05e8b41198e6b7d396f8dd39ae76a2a5856

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&#39;re =
pointing to, I&#39;m using the term &quot;high standard&quot; 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&#39;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 &quot;done&quot;. 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&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:aliashraf.btc@protonmail.com">=
aliashraf.btc@protonmail.com</a>&gt; 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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br=
>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">Hi Michael,<div><br></div><br><div>I&#39;m
thinking such a covenant effort would be more a technical process aiming
 to advance the state of covenant &amp; 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&#39;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--