Re: [bitcoin-dev] On a new community process to specify covenants

["aliashraf.btc At protonmail" <aliashraf.btc@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

------- 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: 2627 bytes --]