Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BCA7DC002D for ; 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 ; 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 ; 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 ; Tue, 26 Jul 2022 03:18:15 +0000 (UTC) Received: by mail-il1-x130.google.com with SMTP id u19so6688569ilk.7 for ; 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: In-Reply-To: From: Antoine Riard Date: Mon, 25 Jul 2022 23:18:03 -0400 Message-ID: To: "aliashraf.btc At protonmail" Content-Type: multipart/alternative; boundary="00000000000044f9d505e4acc023" 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: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
Hi aliashraf,

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.

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.

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/bitc= oin/issues/22806

Le=C2=A0dim. 24 juil. 2022 =C3=A0=C2=A009:01, alias= hraf.btc At protonmail <= aliashraf.btc@protonmail.com> a =C3=A9crit=C2=A0:
------- 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 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]

Hi Antoine,
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.

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.

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,

Cheers,


--00000000000044f9d505e4acc023--