Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-26 📝 Original message:Hi aliashraf, Well, ...
📅 Original date posted:2022-07-26
📝 Original message: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 at protonmail.com> a écrit :
> ------- Original Message -------
> On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at 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,
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220725/8a20f23d/attachment-0001.html>;
📝 Original message: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 at protonmail.com> a écrit :
> ------- Original Message -------
> On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev <
> bitcoin-dev at 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,
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220725/8a20f23d/attachment-0001.html>;