Delivery-date: Fri, 06 Dec 2024 17:10:15 -0800
Sender: bitcoindev@googlegroups.com
Date: Fri, 6 Dec 2024 16:29:50 -0800 (PST)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6d375199-834e-4630-8b5c-fcc5ed137cb1n@googlegroups.com>
In-Reply-To: <941b8c22-0b2c-4734-af87-00f034d79e2e@gmail.com>
References: <028c0197-5c45-4929-83a9-cfe7c87d17f4n@googlegroups.com>
 <941b8c22-0b2c-4734-af87-00f034d79e2e@gmail.com>
Subject: Re: [bitcoindev] Covenants Support - Bitcoin Wiki
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_159906_2081262242.1733531390653"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_159906_2081262242.1733531390653
Content-Type: multipart/alternative; 
	boundary="----=_Part_159907_1496702116.1733531390653"

------=_Part_159907_1496702116.1733531390653
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=20
include community support. If a developer wants to ACK a proposal it is=20
possible to use to 'prefer' or 'acceptable' and 'no' for NACK.=20

We have already changed definition for 3 categories. I removed community=20
support from 'no' and moonsettler rephrased 'prefer' and 'evaluating'.=20
Removing some categories at this point breaks the whole table.=20

At the end of the day bitcoin developers build for community so if someone=
=20
wants to play safe and use 'deficient' and 'wanting', its their choice and=
=20
I think we should allow such freedom to express themselves.=20

>  2. Require Stating Reasons for Objections

A column for adding a link to rationale will be added this weekend. I had=
=20
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 achieve=
d
> rough developer consensus.

>  Developers giving positive technical evaluations are also encouraged to=
=20
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=
=20
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=E2=80=AFAM UTC+5:30 Jonas Nick wro=
te:

> 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=
=20
> lacks
> key characteristics that would help in (rough) consensus building as=20
> 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,=
=20
> but
> the ratings already assume certain levels of support. This makes the=20
> 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 meaningf=
ul
> discussion. Each "No" rating should include a link to a mailing list post=
=20
> or
> similar document that explicitly states the objection, covering aspects=
=20
> 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 achieve=
d
> rough developer consensus.
>
> Developers giving positive technical evaluations are also encouraged to=
=20
> 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 draf=
t
> BIPs. These should be linked to provide a clear basis for technical
> evaluation.
>
> [0] https://datatracker.ietf.org/doc/html/rfc7282
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
6d375199-834e-4630-8b5c-fcc5ed137cb1n%40googlegroups.com.

------=_Part_159907_1496702116.1733531390653
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonas,<br /><br />Thank you for reviewing the wiki page.<br /><div><br /=
></div><div>&gt;=C2=A01. Separate Technical Evaluation from Community Suppo=
rt<br />&gt; A simple solution would be to remove the "Wanting" and "Defici=
ent"<br />categories.<br /><br />There are 7 options available to share opi=
nion on an opcode and only 2 include community support. If a developer want=
s to ACK a proposal it is possible to use to 'prefer' or 'acceptable' and '=
no' for NACK.=C2=A0<br /><br />We have already changed definition for 3 cat=
egories. I removed community support from 'no' and moonsettler rephrased 'p=
refer' and 'evaluating'. Removing some categories at this point breaks the =
whole table.=C2=A0<br /><br />At the end of the day bitcoin developers buil=
d for community so if someone wants to play safe and use 'deficient' and 'w=
anting', its their choice and I think we should allow such freedom to expre=
ss themselves.=C2=A0<br /><br />&gt;=C2=A0

2. Require Stating Reasons for Objections<br /><br />A column for adding a =
link to rationale will be added this weekend. I had tweeted about it but fo=
rgot to update the mailing list thread.<br /><br />&gt;=C2=A0

Because there is no working group making decisions in Bitcoin,<br />&gt; co=
mmunity members must individually assess whether proposals have achieved<br=
 />&gt; rough developer consensus.<br /><br />&gt;=C2=A0

Developers giving positive technical evaluations are also encouraged to sha=
re<br />&gt; their reasoning, as this can help inform others' assessments.<=
br /><br />I agree with you on this and I have requested everyone to respon=
d to this thread.<br /><br />&gt;=C2=A0

3. Add Links to BIP Drafts<br /><br />I have added the links to BIP drafts =
for all opcodes.</div><div><br /></div><div>/dev/fd0</div><div>floppy disk =
guy<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"=
gmail_attr">On Saturday, December 7, 2024 at 4:18:21=E2=80=AFAM UTC+5:30 Jo=
nas Nick wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;">Hi /dev/fd0,
<br>
<br>I do not think the segwit support page serves as a suitable template fo=
r
<br>building rough consensus, in general and for covenants in particular. I=
t lacks
<br>key characteristics that would help in (rough) consensus building as ou=
tlined in
<br>RFC 7282 [0] (which I strongly recommend reading).
<br>
<br>I propose the following changes:
<br>
<br>1. Separate Technical Evaluation from Community Support
<br>
<br>    The ratings &quot;Deficient&quot; and &quot;Wanting&quot; are suppo=
sed to be assigned when a
<br>    proposal considered to have insufficient community support. This cr=
eates a
<br>    circular problem: the wiki page is meant to help build community su=
pport, but
<br>    the ratings already assume certain levels of support. This makes th=
e ratings
<br>    less useful and risks creating self-fulfilling prophecies.
<br>
<br>    A simple solution would be to remove the &quot;Wanting&quot; and &q=
uot;Deficient&quot;
<br>    categories.
<br>
<br>2. Require Stating Reasons for Objections
<br>
<br>    As RFC 7282 states:
<br>
<br>    &gt; Remember, coming to consensus is a matter of eliminating disag=
reement.
<br>
<br>    To achieve this, we need to clearly state objections to enable a me=
aningful
<br>    discussion. Each &quot;No&quot; rating should include a link to a m=
ailing list post or
<br>    similar document that explicitly states the objection, covering asp=
ects such
<br>    as technical deficiencies, likelihood of widespread adoption, and i=
mpact on
<br>    decentralization.
<br>
<br>    &gt; Then, the purported failings
<br>    &gt; of the choice can be examined by the working group.  The objec=
tor
<br>    &gt; might convince the rest of the group that the objections are v=
alid
<br>    &gt; and the working group might choose a different path.  Converse=
ly, the
<br>    &gt; working group might convince the objector that the concerns ca=
n be
<br>    &gt; addressed, or that the choice is simply unappealing (i.e., som=
ething
<br>    &gt; the objector can &quot;live with&quot;) and not a show-stopper=
.
<br>
<br>    Because there is no working group making decisions in Bitcoin,
<br>    community members must individually assess whether proposals have a=
chieved
<br>    rough developer consensus.
<br>
<br>    Developers giving positive technical evaluations are also encourage=
d to share
<br>    their reasoning, as this can help inform others&#39; assessments.
<br>
<br>3. Add Links to BIP Drafts
<br>
<br>    All opcodes mentioned on the wiki page presumably have correspondin=
g draft
<br>    BIPs. These should be linked to provide a clear basis for technical
<br>    evaluation.
<br>
<br>[0] <a href=3D"https://datatracker.ietf.org/doc/html/rfc7282" target=3D=
"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/ur=
l?hl=3Den&amp;q=3Dhttps://datatracker.ietf.org/doc/html/rfc7282&amp;source=
=3Dgmail&amp;ust=3D1733614799815000&amp;usg=3DAOvVaw2CyErV4cO1T84zeV2G9-HC"=
>https://datatracker.ietf.org/doc/html/rfc7282</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/6d375199-834e-4630-8b5c-fcc5ed137cb1n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/6d375199-834e-4630-8b5c-fcc5ed137cb1n%40googlegroups.com</a>.<br />

------=_Part_159907_1496702116.1733531390653--

------=_Part_159906_2081262242.1733531390653--