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------- 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,