path: root/39/56758b8790a1390a6d159d3d9e35043d7aa9be

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48AD9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 05:18:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 2213E4016C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 05:18:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id r8iWH9KfZlqv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 05:18:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6D4EA400FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 05:18:23 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id e23so4189443eda.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 22:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=ucVWfIMPV/qCMyz0iZo/+4GKtlN7KpjIAVAC4Y/Pg8c=;
 b=nfJv1k0A+SXabPb5mgihYLiF1bwVfMhC09ipV05JmlMEPwArP3WkUIwcSJg4q0PR4N
 htAnRSHKS8IS/31NQnX0HVjeFDPOGRlfHTvFzwnpFgonV0FJroInfXoY/2DysuicmFIF
 NSoq/gAfv5Z2QHRW40WdNpzNI/IU3oia/trBwD8npov1CgQfPymBB5VMmyRXdR3I280P
 RXokYvJxW2/gnOeUMvZHLrfApQ5Td92EnYhR2nNLKaaiswV3fYF7IjDKTiDA7RByFgUK
 ajsVytoYdr7ZDpJHFe9FfialMunVlwOplmqHaS8j8HNHpx3NYUePCI6kroSbKzR2IfcK
 9HAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=ucVWfIMPV/qCMyz0iZo/+4GKtlN7KpjIAVAC4Y/Pg8c=;
 b=CW+QVAug6iku4/oubO8SmnQWyqt//oPKPlsgzEIcxi2xr00XCWMtfRT537579rVdcr
 7hNvFJYfkRTDD7s7KvsS1SpbsRZKO/XekJH2daMZzMECFTtr20z8M1z3f2ZmLhbtugQl
 EsFpVMsVoaB6QLLqD5xOqUglKv2Ja+anlxVnGeGO1in/gZixpUanDf8wn2UCRHLx9Eur
 VNpePfGsy72ezmbMboc1hKZmIB2j4orMM4XrFhwvlNEoz3wNRnC4LuDziW8yJsgwZoiA
 58YY6RP5VFqRjzgMo7V2yj8bzW/mfvIOBeEBGPRXs/Af7LkP02lbIOHxPcH3B1VBpWBa
 8LYQ==
X-Gm-Message-State: AOAM531aGb6UTZ5znBEGR/TgrTRJGgkhOySdoUTZLXlRxhB96jiv6Pva
 bPgsG9rYA3+wLfYjauwoaTsdtPylOSygG7xHAVAk8quF8Lg=
X-Google-Smtp-Source: ABdhPJwBUCu7CqVjCNJFSb5GiOYoi7jes7dHiIAKkvYgD3aQ2XSDBSFyrBWRjuWtD/45YdaWWfnTeFt1dSig6OCeGSU=
X-Received: by 2002:a05:6402:2787:b0:425:fa59:ebf8 with SMTP id
 b7-20020a056402278700b00425fa59ebf8mr13297137ede.53.1651123101372; Wed, 27
 Apr 2022 22:18:21 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
 <CABaSBayKH__f_ahUUiDt2SiKik9aNLR1AXtG9RtWrFmTLP5qKw@mail.gmail.com>
 <CAGpPWDbYj4+g4VPMT9FPqyUZWO+U98YQhgYan5fRqXjpd+dTyw@mail.gmail.com>
 <CAL5BAw1pKXh4HLrUQByVMwpUtYyWcE5JhjUP-JB_1HKkORB1dA@mail.gmail.com>
 <CAJowKg+-qy00X_nSvFDz0HtvfjdsaozzGq4Vr8Vbd06GGZ8k_A@mail.gmail.com>
 <CAGpPWDaDRROKQdQ0WcK-RHo5=dQL6tD=LcQbqfS6p8ZEWkpEmA@mail.gmail.com>
 <CAJowKgL5kgWkSB=8ioFkfCxmRJLif-P4VSvX04Ubz_h8A3XYtA@mail.gmail.com>
In-Reply-To: <CAJowKgL5kgWkSB=8ioFkfCxmRJLif-P4VSvX04Ubz_h8A3XYtA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 28 Apr 2022 00:18:06 -0500
Message-ID: <CAGpPWDZ_3gffJsdofpLQDg5F6Qg03G+5897SJENQEhVv0d-jrg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="000000000000f0124305ddb00df6"
X-Mailman-Approved-At: Thu, 28 Apr 2022 08:46:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Towards a means of measuring user support for
	Soft Forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 05:18:25 -0000

--000000000000f0124305ddb00df6
Content-Type: text/plain; charset="UTF-8"

  @Felipe
> the consensus should follow the current line: discussions and tests
carried out by experts. We all know that the most important devs have the
most weight in discussions. And that's how it should be

We have up til this point been miraculously lucky that the vast majority of
prominent bitcoin developers are in relative alignment on the big picture
philosophy and have all seemed to be honest and open in general. However,
we cannot rely on this era of philosopher kings to continue. Relying on
experts in this way is an enormous attack vector. It should not be the
"most important" devs who carry the most weight, but weight should be
carried by the logic of what is being said. The speaker should ideally not
matter in consensus building. So I agree with Keagan's implication that
this is not how bitcoin should govern itself. We should move away from
appeals to authority towards something more amorphous and difficult to
control.

@Jeremy
> if there were a way to sign with a NUMS point for ring signature purposes

Do you have any link you could point to about NUMS points? I assume this
would be a way to aggregate coin-weighted signals in a way that helps hide
who signaled in what direction?

> if NUMS points are common these ring signatures protocols might not be
too useful for collecting signals

I'm curious: why is it better if its less common? I'm used to privacy
properties increasing as the privacy technique used becomes more common.

@Erik
> it doesn't address the "what about people who don't know there's a vote
going on"
> how nonexperts can "have a say" when they simply don't understand the
relevant issues.

I think a useful way to think about this is in terms of preferences and
representation, rather than in the terms of coming to the best technical
solution. The fact of the matter is that value is subjective and therefore
there is no "best" technical solution all the time. Sometimes the
preferences of stakeholders must be weighed and a compromise come to.
Hopefully most of these kinds of compromises can happen in the free market
on upper layers. But certainly some of them happen on the consensus layer.

An expert with deep knowledge can deeply understand a design or change well
enough to come to a full opinion about it according to their preferences.
But even other experts might not have read enough about a thing, or just
don't have time to delve deeply into that particular aspect. They'll have
to rely partly on their ability to make a determination from partial
knowledge and their ability to evaluate the trustworthiness and skill of
those who have deeper knowledge than them. Nonexperts and non-technical
people have to rely on those kinds of things even more so. Many people only
have social signals to rely on. What do the people they trust say?

I believe that the truth gets out eventually. Those who have deep knowledge
will eventually convince those who don't, tho that may take a long time to
play out. As annoying as the twitterati is, I think we should get used to
needing to give their opinions a bit of weight in terms of measuring
consensus. Of course, we shouldn't be making technical decisions based on
what nontechnical people want or think, however, what we should do is make
sure that we are explaining the changes we propose to make clearly enough
that a certainly level of comfort diffuses into the social circles of
people who care about bitcoin but don't understand it at a technical enough
level to participate in technical decision making. At a certain point, if
not enough people are comfortable with a change, the change shouldn't be
made yet until enough people are convinced its probably safe and probably
good. Think of the large set of non-technical people to be a glue that
connects together otherwise unconnected pockets of wisdom.

Doing things this way would almost certainly lead to slower development.
But development of the consensus layer slowing over time should be what we
all expect, and I daresay what we should all want eventually.

> it will just be a poll of "people who pay attention to the dev list and
maybe some irc rooms"

Maybe. But if there were mechanisms for broader consensus measuring,
perhaps more would pay attention. Perhaps some way to affect change would
lead more to have discussions and participate.

Even if its a small group at first, I think it would be very useful
information to see both who explicitly supports something, who explicitly
is against something, and also who is paying attention but neutral (maybe
even actively signaling as "neutral').

> unless there's a great ux around the tooling my guess is that it won't
garner a lot of meaningful data:

I agree. Tooling would be very important here.







On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty <erik@q32.com> wrote:

>
>>
>> Have you taken a look at my proposal
>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>?
>> The proposal is, to be clear, *not* "voting" but rather polling that isn't
>> programmatically connected to activation. The intention is for people
>> (developers) to look at the polling results and make an educated analysis
>> of it as far as how it should contribute to consensus gathering.
>>
>
> it's cool, and i agree it's somewhat censorship resistant
>
>
>> Let's say everyone who participates in polling broadcasts it along the
>> bitcoin network (a separate network would probably be better, so as to not
>> interfere with normal bitcoin, but I digress),
>>
>
> right, anyone can then publish a json file with polling aggregates at a
> certain block height and anyone can quickly check to see if they are lying
> or missing data
>
>
>> Similar structures could be added to any script configuration to allow
>> signing of polls without any significant exposure.
>>
>
> rubin's suggestion around tapscript anon voting could help with anonymity
>
> .... all of this is cool ...
>
> but it doesn't address the "what about people who don't know there's a
> vote going on"  or other the other social issues with "weighted polling" in
> general, like how nonexperts can "have a say" when they simply don't
> understand the relevant issues.  i personally feel like i'm "only a very
> little bit up on the issues" and i have more tech knowledge than most
> people i know
>
> also, it will just be a poll of "people who pay attention to the dev list
> and maybe some irc rooms"
>
> might be worth experimenting with... but unless there's a great ux around
> the tooling my guess is that it won't garner a lot of meaningful data:
>
> open source, simple cli, gitian build, installs easily on all platforms,
> works well with bitcoind rpc, works with ledger, can import a seed, etc.
>
>

--000000000000f0124305ddb00df6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>=C2=A0 @Felipe<br><div>&gt;=C2=A0<span style=3D"color=
:rgb(0,0,0);font-family:arial,helvetica,sans-serif">the consensus should fo=
llow the current line: discussions and tests carried out by experts. We all=
 know that the most important devs have the most weight in discussions. And=
 that&#39;s how it should be</span></div><div><span style=3D"color:rgb(0,0,=
0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span styl=
e=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">We have up ti=
l this point been miraculously lucky that the vast majority of prominent=C2=
=A0bitcoin developers are in relative alignment on the big picture philosop=
hy and have all seemed to be honest and open in general. However, we cannot=
 rely on this era of philosopher kings to continue. Relying on experts in t=
his way is an enormous attack vector. It should not be the &quot;most impor=
tant&quot; devs who carry the most weight, but weight should be carried by =
the logic of what is being said. The speaker should ideally not matter in c=
onsensus building. So I agree with=C2=A0Keagan&#39;s implication that this =
is not how bitcoin should govern itself. We should move away from appeals t=
o authority towards something more amorphous and difficult to control.</spa=
n></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sa=
ns-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family=
:arial,helvetica,sans-serif">@Jeremy<br>&gt;=C2=A0</span><span style=3D"col=
or:rgb(0,0,0);font-family:arial,helvetica,sans-serif">if there were a way t=
o sign with a NUMS point for ring signature purposes</span></div><div><span=
 style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></sp=
an></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,s=
ans-serif">Do you have any link you could point to about NUMS points? I ass=
ume this would be a way to aggregate coin-weighted signals in a way that he=
lps hide who signaled in what direction?=C2=A0</span></div><div><span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></d=
iv><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-se=
rif">&gt;=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:arial,hel=
vetica,sans-serif">if NUMS points are common these ring signatures protocol=
s might not be too useful for collecting signals=C2=A0</span></div><div><sp=
an style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></=
span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica=
,sans-serif">I&#39;m curious: why is it better if its less common? I&#39;m =
used to privacy properties increasing as the privacy technique used becomes=
 more common.</span></div><div></div></div><div><span style=3D"color:rgb(0,=
0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div>@Erik<br=
></div><div>&gt; it doesn&#39;t address the &quot;what about people who don=
&#39;t know there&#39;s a vote going on&quot;=C2=A0</div><div>&gt; how none=
xperts can &quot;have a say&quot; when they simply don&#39;t understand the=
 relevant issues.</div><div><br></div><div>I think a useful way to think ab=
out this is in terms of preferences and representation, rather than in the =
terms of coming to the best technical solution. The fact of the matter is t=
hat value is subjective and therefore there is no &quot;best&quot; technica=
l solution all the time. Sometimes the preferences of stakeholders must be =
weighed and a compromise=C2=A0come to. Hopefully most of these kinds of com=
promises can happen in the free market on upper layers. But certainly some =
of them happen on the consensus layer.=C2=A0</div><div><br></div><div>An ex=
pert with deep knowledge can deeply understand a design or change well enou=
gh to come to a full opinion about it according to their preferences. But e=
ven other experts might not have read enough about a thing, or just don&#39=
;t have time to delve deeply into that particular aspect. They&#39;ll have =
to rely partly on their ability to make a determination from partial knowle=
dge and their ability to evaluate the trustworthiness and skill of those wh=
o have deeper knowledge than them. Nonexperts=C2=A0and non-technical people=
 have to rely on those kinds of things even more so. Many people only have =
social signals to rely on. What do the people they trust say?=C2=A0</div><d=
iv><br></div><div>I believe that the truth gets out eventually. Those who h=
ave deep knowledge will eventually convince those who don&#39;t, tho that m=
ay take a long time to play out. As annoying as the twitterati is, I think =
we should get used to needing to give their opinions a bit of weight in ter=
ms of measuring consensus. Of course, we shouldn&#39;t be making technical =
decisions based on what nontechnical people want or think, however, what we=
 should do is make sure that we are explaining the changes we propose to ma=
ke clearly enough that a certainly level of comfort diffuses into the socia=
l circles of people who care about bitcoin but don&#39;t understand it at a=
 technical enough level to participate in technical decision making. At a c=
ertain point, if not enough people are comfortable with a change, the chang=
e shouldn&#39;t be made yet until enough people are convinced its probably =
safe and probably good. Think of the large set of non-technical people to b=
e a glue that connects together otherwise unconnected pockets of wisdom.=C2=
=A0</div><div><br></div><div>Doing things this way would almost certainly l=
ead to slower development. But development of the consensus layer slowing o=
ver time should be what we all expect, and I daresay what we should all wan=
t eventually.=C2=A0</div><div><br></div><div>&gt; it will just be a poll of=
 &quot;people who pay attention to the dev list and maybe some irc rooms&qu=
ot;<br></div><div><br></div><div>Maybe. But if there were mechanisms for br=
oader consensus measuring, perhaps more would pay attention. Perhaps some w=
ay to affect change would lead more to have discussions and participate.=C2=
=A0</div><div><br></div><div>Even if its a small group at first, I think it=
 would be very useful information to see both who explicitly supports somet=
hing, who explicitly is against something, and also who is paying attention=
 but neutral (maybe even actively signaling as &quot;neutral&#39;).</div><d=
iv><br></div><div>&gt; unless there&#39;s a great ux around the tooling my =
guess is that it won&#39;t garner a lot of meaningful data:</div><div><br><=
/div><div>I agree. Tooling would be very important here.</div><div><br></di=
v><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-ser=
if"><br></span></div><div><br></div><div><br></div><div><br></div><div><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></s=
pan></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty &lt;<a href=3D"mail=
to:erik@q32.com">erik@q32.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br><=
br></div><div>Have you taken a look at <a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-March/020146.html" target=3D"_blank">my=
 proposal</a>? The proposal is, to be clear, *not* &quot;voting&quot; but r=
ather polling that isn&#39;t programmatically connected to activation. The =
intention is for people (developers) to look at the polling results and mak=
e an educated analysis of it as far as how it should contribute to consensu=
s gathering.=C2=A0</div></div></blockquote><div><br></div><div>it&#39;s coo=
l, and i agree it&#39;s somewhat censorship resistant</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Le=
t&#39;s say everyone who participates in polling broadcasts it along the bi=
tcoin network (a separate network would probably be better, so as to not in=
terfere with normal bitcoin, but I digress), </div></div></blockquote><div>=
<br></div><div>right, anyone can then publish a json file with polling aggr=
egates at a certain block height and anyone can quickly check to see if the=
y are lying or missing data<br>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>Similar structures could be added t=
o any script configuration to allow signing of polls without any significan=
t exposure.<br></div></div></blockquote><div><div><br></div>rubin&#39;s sug=
gestion around tapscript=C2=A0anon voting could help with anonymity<br>=C2=
=A0<br>.... all of this is cool ...</div><div><br></div><div>but it doesn&#=
39;t address the &quot;what about people who don&#39;t know there&#39;s a v=
ote going on&quot;=C2=A0 or other the other social issues with &quot;weight=
ed polling&quot; in general, like how nonexperts can &quot;have a say&quot;=
 when they simply don&#39;t understand the relevant issues.=C2=A0 i persona=
lly feel like i&#39;m &quot;only a very little bit up on the issues&quot; a=
nd i have more tech knowledge than most people i know<br><br>also, it will =
just be a poll of &quot;people who pay attention to the dev list and maybe =
some irc rooms&quot;<br></div></div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote"><div>might be worth experimenting with... but unle=
ss there&#39;s a great ux around the tooling my guess is that it won&#39;t =
garner a lot of meaningful data:</div><div><br></div><div>open source, simp=
le cli, gitian build, installs easily on all platforms, works well with bit=
coind rpc, works with ledger, can import a seed, etc.=C2=A0=C2=A0</div><div=
 class=3D"gmail_quote"><br></div></div></div>
</blockquote></div>

--000000000000f0124305ddb00df6--