------- 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,
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
