path: root/44/c625ff2928ddc0b2736b8b09abb218766c91cd

Delivery-date: Fri, 06 Dec 2024 17:10:15 -0800
Received: from mail-yw1-f191.google.com ([209.85.128.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBB3OAZ25AMGQE4WGKIHI@googlegroups.com>)
	id 1tJjKo-0001FD-Iy
	for bitcoindev@gnusha.org; Fri, 06 Dec 2024 17:10:15 -0800
Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-6ef8494edb2sf26309977b3.2
        for <bitcoindev@gnusha.org>; Fri, 06 Dec 2024 17:10:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1733533808; x=1734138608; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=MgCjooEWZMwuO0Gbxbl8/fDBYDmh8bLdFD44jGq/Muk=;
        b=k+z09H/b77nn0mrHu4HSAl1US53HqUFF4f+oRMMwESKAim/JqwMxMDdeJeuOOXEFRO
         OdYDE67UxqdW5SLd2JeutOCqXF0s+68hY4cL53p0lEYTyiGbfPI7d6HqtLCiY+8MIS7Y
         jGrICMU0/lA/NFxkAWzUMhRrMwJIYWMNojYsSV+tXL57W3Rc2ZJQk7l5hKSHFxKmyvud
         r5EerWT+nNKIHZ1fQl+k2zsSV0TnLGIvFNBPQ4A01wf99J9SACVpg61ImXMBPO01K8Ok
         K+aGQJ1nTWl3rqXgzdc3YGMSDx7+20OC/S0kEZOL/feSqQ2hHZVwRT/l0T9mKrF4Rch6
         h0Gw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733533808; x=1734138608; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MgCjooEWZMwuO0Gbxbl8/fDBYDmh8bLdFD44jGq/Muk=;
        b=T0gCM3MJmOWaeOcY94GcdYG0j0AXt+fu4sV3BBXsuPQ7wMcuOlQtwSg5ioi5UddqTn
         M74sRGSPNujUerugzKOLLOn8cVs60MNIl0CiFnzsWbIvTYhbwLN1umsmd6Z/3K/j3vkb
         ZEyQWpOUudKAe+JbECDd+RO3SoMa9S3pYfApdjVXP0V2aJi4zBoDMT8TPDqVMabefl1E
         d6w1dg1H8pw2LgCX9rC7bOV6392+9EeRffqCxUH5Kt4aJzfFYyiSYzTn3p2fwfFxu2CE
         lHJ1OzaJpxOrAdZHMW7k7dNvQOjLBevo7Kh1Lm0JaqRaUQX/DkvZPpAX4KWgF5GV1T8L
         E4hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733533808; x=1734138608;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=MgCjooEWZMwuO0Gbxbl8/fDBYDmh8bLdFD44jGq/Muk=;
        b=OdWhTnNYc1TZpOeXTmMI/kksHiimBquBxrdKKPFlPpF2sq3PS3fPevml1RTbCSvxyU
         dMIAZqBFwtxlTOEIWy1l7oHM2WJ8xlM6bdi9Edm5nzZ8dRN/TKAmuFd1t2+gOqO3vrSh
         7XGgd8cq2GvX6PiU3Wzi6n34p/XWB52UNufDZvJjf8pze4bWrlP0ABL7GukfS0DMLcQj
         7d+EC56WtLRFuGZENe4+C8dr+xKmganv+p7+sVAmTicRq3MjQWrZ/+rdeYN5AJ+kIjxY
         Yh/NHGEh2pIkMEK1+llWPqfWMLriPBwRMTTYRdGEdqh/uKEkp8hv9Wehgf2skSIXXBOf
         7K5g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXCVn5HhkeuxM+CQAi+b0orem3S7TPOwL73TUBZfT3/wR3wUlZUcLYzymN7NVNwFYfNw2kHnUAVjxig@gnusha.org
X-Gm-Message-State: AOJu0YyotHnUOs/a2Oocuep7jZ5RK+oWWBJD2rC6uJakzWs/zLJevsJY
	AZTtA2dWU8+HmotPUVtsothmdLcupMYcUxPjPUPs58iZ6WmsEZ+A
X-Google-Smtp-Source: AGHT+IFaJriTQhHLWypP8RZmoj5qqkQKUKO9kVEgmBHITV59uLGV5pAnShmwFMzsvqtbGfznOG7ieg==
X-Received: by 2002:a05:6902:2b8f:b0:e2b:d505:86a9 with SMTP id 3f1490d57ef6-e3a0b07c680mr4153091276.4.1733533807857;
        Fri, 06 Dec 2024 17:10:07 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:df51:0:b0:e38:7d9d:de43 with SMTP id 3f1490d57ef6-e39f201ed63ls818197276.2.-pod-prod-02-us;
 Fri, 06 Dec 2024 17:10:04 -0800 (PST)
X-Received: by 2002:a05:690c:6d10:b0:6ef:5fee:1c92 with SMTP id 00721157ae682-6efe3bceb1emr64849127b3.2.1733533804724;
        Fri, 06 Dec 2024 17:10:04 -0800 (PST)
Received: by 2002:a05:690c:4092:b0:6ef:7d10:5a2f with SMTP id 00721157ae682-6efe3f0fab7ms7b3;
        Fri, 6 Dec 2024 16:29:51 -0800 (PST)
X-Received: by 2002:a05:690c:4d43:b0:6ee:9cb7:dc24 with SMTP id 00721157ae682-6efe3c74e88mr54806237b3.38.1733531390847;
        Fri, 06 Dec 2024 16:29:50 -0800 (PST)
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"
X-Original-Sender: alicexbtong@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_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--