From: Antoine Riard <antoine.riard@gmail•com>
To: "aliashraf.btc At protonmail" <aliashraf.btc@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Mon, 25 Jul 2022 23:18:03 -0400 [thread overview]
Message-ID: <CALZpt+F9OeUij1LzvqK0RkB9Ov6v-it_Jrp4KAXFoOt=OTrmcw@mail.gmail.com> (raw)
In-Reply-To: <oYPIKqafRHCflmFrB8HcUnhyFabJo7u4sT8w8DPBIQ1lWcuQGiPs-dhJiupOdCnmrc_3zRhq36VngKBgSXee-hFoe6C_sUYkcz9hNz1cfAA=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
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 à 09:01, aliashraf.btc At protonmail <
aliashraf.btc@protonmail•com> a écrit :
> ------- 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 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 challenges,
> 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 more
> agile approaches and their inevitable effect on the course of discussions,
>
> Cheers,
>
>
>
[-- Attachment #2: Type: text/html, Size: 4447 bytes --]
next prev parent reply other threads:[~2022-07-26 3:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 20:42 Antoine Riard
2022-07-23 5:09 ` Ryan Grant
2022-07-23 14:57 ` Antoine Riard
2022-07-23 14:25 ` Michael Folkson
2022-07-23 16:41 ` Antoine Riard
2022-07-24 13:01 ` aliashraf.btc At protonmail
2022-07-24 23:40 ` ZmnSCPxj
2022-07-26 3:20 ` Antoine Riard
2022-07-26 3:18 ` Antoine Riard [this message]
2022-07-24 18:22 ` Bram Cohen
2022-07-24 20:26 ` aliashraf.btc At protonmail
2022-07-26 3:21 ` Antoine Riard
2022-07-26 16:02 ` Bram Cohen
2022-08-03 15:37 ` Billy Tetrud
2022-08-09 20:15 ` Antoine Riard
2022-08-27 21:01 ` Billy Tetrud
2022-08-30 15:46 ` Antoine Riard
2022-09-10 0:10 ` Antoine Riard
2022-10-07 15:33 ` Antoine Riard
2022-09-12 0:05 Buck O Perley
2022-09-13 16:02 ` Ryan Grant
2022-09-15 8:05 ` Devrandom
2022-09-16 19:08 ` Antoine Riard
2022-09-16 18:59 ` Antoine Riard
2022-09-17 7:52 ` Devrandom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+F9OeUij1LzvqK0RkB9Ov6v-it_Jrp4KAXFoOt=OTrmcw@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=aliashraf.btc@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox