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