Subject: Re: [bitcoindev] Covenants Support - Bitcoin Wiki

From: Jonas Nick <[email-masked]>
Date: Fri, 6 Dec 2024 21:45:31 +0000

Hi /dev/fd0,

I do not think the segwit support page serves as a suitable template for
building rough consensus, in general and for covenants in particular. It lacks
key characteristics that would help in (rough) consensus building as outlined in
RFC 7282 [0] (which I strongly recommend reading).

I propose the following changes:

1. Separate Technical Evaluation from Community Support

    The ratings "Deficient" and "Wanting" are supposed to be assigned when a
    proposal considered to have insufficient community support. This creates a
    circular problem: the wiki page is meant to help build community support, but
    the ratings already assume certain levels of support. This makes the ratings
    less useful and risks creating self-fulfilling prophecies.

    A simple solution would be to remove the "Wanting" and "Deficient"
    categories.

2. Require Stating Reasons for Objections

    As RFC 7282 states:

    > Remember, coming to consensus is a matter of eliminating disagreement.

    To achieve this, we need to clearly state objections to enable a meaningful
    discussion. Each "No" rating should include a link to a mailing list post or
    similar document that explicitly states the objection, covering aspects such
    as technical deficiencies, likelihood of widespread adoption, and impact on
    decentralization.

    > Then, the purported failings
    > of the choice can be examined by the working group.  The objector
    > might convince the rest of the group that the objections are valid
    > and the working group might choose a different path.  Conversely, the
    > working group might convince the objector that the concerns can be
    > addressed, or that the choice is simply unappealing (i.e., something
    > the objector can "live with") and not a show-stopper.

    Because there is no working group making decisions in Bitcoin,
    community members must individually assess whether proposals have achieved
    rough developer consensus.

    Developers giving positive technical evaluations are also encouraged to share
    their reasoning, as this can help inform others' assessments.

3. Add Links to BIP Drafts

    All opcodes mentioned on the wiki page presumably have corresponding draft
    BIPs. These should be linked to provide a clear basis for technical
    evaluation.

[0] https://datatracker.ietf.org/doc/html/rfc7282

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/941b8c22-0b2c-4734-af87-00f034d79e2e%40gmail.com.