From: /dev /fd0 <alicexbtong@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Covenants Support - Bitcoin Wiki
Date: Fri, 6 Dec 2024 16:29:50 -0800 (PST) [thread overview]
Message-ID: <6d375199-834e-4630-8b5c-fcc5ed137cb1n@googlegroups.com> (raw)
In-Reply-To: <941b8c22-0b2c-4734-af87-00f034d79e2e@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4479 bytes --]
Hi Jonas,
Thank you for reviewing the wiki page.
> 1. Separate Technical Evaluation from Community Support
> A simple solution would be to remove the "Wanting" and "Deficient"
categories.
There are 7 options available to share opinion on an opcode and only 2
include community support. If a developer wants to ACK a proposal it is
possible to use to 'prefer' or 'acceptable' and 'no' for NACK.
We have already changed definition for 3 categories. I removed community
support from 'no' and moonsettler rephrased 'prefer' and 'evaluating'.
Removing some categories at this point breaks the whole table.
At the end of the day bitcoin developers build for community so if someone
wants to play safe and use 'deficient' and 'wanting', its their choice and
I think we should allow such freedom to express themselves.
> 2. Require Stating Reasons for Objections
A column for adding a link to rationale will be added this weekend. I had
tweeted about it but forgot to update the mailing list thread.
> 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.
I agree with you on this and I have requested everyone to respond to this
thread.
> 3. Add Links to BIP Drafts
I have added the links to BIP drafts for all opcodes.
/dev/fd0
floppy disk guy
On Saturday, December 7, 2024 at 4:18:21 AM UTC+5:30 Jonas Nick wrote:
> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6d375199-834e-4630-8b5c-fcc5ed137cb1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5731 bytes --]
next prev parent reply other threads:[~2024-12-07 1:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 14:08 /dev /fd0
2024-12-06 21:45 ` Jonas Nick
2024-12-07 0:29 ` /dev /fd0 [this message]
2024-12-07 1:42 ` Yuval Kogman
2024-12-09 20:13 ` Anthony Towns
2024-12-09 20:45 ` Brandon Black
2024-12-11 13:28 ` Anthony Towns
2024-12-11 15:11 ` Brandon Black
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d375199-834e-4630-8b5c-fcc5ed137cb1n@googlegroups.com \
--to=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox