path: root/53/2310a757e8155ef357477ac0199ff8fe0a804c

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 A145EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 16:35:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8F726403C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 16:35:55 +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 gcuocMnB_MWb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 16:35:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [IPv6:2a00:1450:4864:20::62c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 7D20F400F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 16:35:52 +0000 (UTC)
Received: by mail-ej1-x62c.google.com with SMTP id r13so10681019ejd.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 09:35:52 -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=ZzcOl9/v026b/IVTVqZ9SW526zbWbHiWC5gzQSp4gmE=;
 b=QjsqIzRMIfqtDJTD7Fg6OdCBxrgFZsISpnQQi80jTI0uMxRlLAll8IgcabiRVgPd9b
 +zTvLuHONnR7J42AXjhZHN1HiZe/0p94u3aegP8cr4kOLUbhveSk7ejujl9vqwRp3Maj
 oZnRUSIyboatAkitmOjlRhSxLSJ2g6YPoW07n4yqnl2YtK6LzaDBiuNLSI7OQRAYr0ye
 +C1LXCMegSQXmCjcA0OhfQKpXiPQMFOkgeTAJC+y176GIfImRF/Tyial+2MvFk8/hhUO
 XtIb+uWZWiNzlTeD4dINR9n91qjc3wWhpOMKF9AwMfYUrZGTno8uDlZzJnCuWqnfmHym
 zoIQ==
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=ZzcOl9/v026b/IVTVqZ9SW526zbWbHiWC5gzQSp4gmE=;
 b=vRSEawC5Ep8IZik+KfRKHd0T8gl2CNhypCuO0bjRcHm5G8gUnS7jhAV1sW9lp5ySOF
 dvjsyT+kQyVzAzur7wqknrmoTjjCFyx9gFvLB1g/Y4LOM0kUQSpuRdJor9uL1DL0p0XE
 NJDTXJyukwgGtfn3vaBLL8XIJCZI3WjcpwN6BuqKIh6jcPy5UfxgDd2YvgxL1XuNBJIL
 dxjgkrcnDUUW+dBXQ1BzCz16nYT4lvTuoP8SVgprIZPYayQ8SLE1lYjnpUkNwCU6T0V9
 crrGiW8f9T7zyCEsahz8obF55lc4CiUlJAsJhUH/BxoLfH4NzcIGnr8j620YHLSGpqYL
 Xz/Q==
X-Gm-Message-State: AOAM530VKnK0EUAK7DctRgVfw16Jv94r7g2MzINMxUEJ2XVvCGaauQDh
 0a8nROzP4G/AqpjE5nR3To50+rFj5VfpIx2Cd9Q=
X-Google-Smtp-Source: ABdhPJzGVNe8JvnEOmW/LT++4YdtyLp5Gx+yF02PKshowx9XmQ3PK5uYHTWuJQ0w9TQr+Ua3FQie7TH2HPFM0Bvdaik=
X-Received: by 2002:a17:906:2991:b0:6cf:6b24:e92f with SMTP id
 x17-20020a170906299100b006cf6b24e92fmr32212118eje.748.1651163750324; Thu, 28
 Apr 2022 09:35:50 -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>
 <CAGpPWDZ_3gffJsdofpLQDg5F6Qg03G+5897SJENQEhVv0d-jrg@mail.gmail.com>
 <CAGpPWDaBcZfH=EhoSbsQHp5nKkJZheMPXudDkDjWX56n9PGB_A@mail.gmail.com>
In-Reply-To: <CAGpPWDaBcZfH=EhoSbsQHp5nKkJZheMPXudDkDjWX56n9PGB_A@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 28 Apr 2022 11:35:32 -0500
Message-ID: <CAGpPWDZqPcufktdNq5DGnpFH=u2VdQTFjJaHQiLaE7jwWhzPUQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="000000000000cddd8605ddb98487"
X-Mailman-Approved-At: Thu, 28 Apr 2022 22:13:55 +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 16:35:55 -0000

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

@Zman
> if two people are perfectly rational and start from the same information,
they *will* agree

I take issue with this. I view the word "rational" to mean basically
logical. Someone is rational if they advocate for things that are best for
them. Two humans are not the same people. They have different circumstances
and as a result different goals. Two actors with different goals will
inevitably have things they rationally and logically disagree about. There
is no universal rationality. Even an AI from outside space and time is
incredibly likely to experience at least some value drift from its peers.

> 3.  Can we actually have the goals of all humans discussing this topic
all laid out, *accurately*?

I think this would be a very useful exercise to do on a regular basis. This
conversation is a good example, but conversations like this are rare. I
tried to discuss some goals
<https://github.com/fresheneesz/bitcoinThroughputAnalysis#general-goals> we
might want bitcoin to have in a paper I wrote about throughput bottlenecks.
Coming to a consensus around goals, or at very least identifying various
competing groupings of goals would be quite useful to streamline
conversations and to more effectively share ideas.

@Nadav
> 1. There's a real cost attached to voting

This is IMO a huge downside. It prevents many from participating at all.
And it also give a big advantage to those who have a large monetary
consequence. It exacerbates the common problem in votes where special
interests spend lots of time and money to get something passed that is bad
overall, while its not bad enough for most people to spend time and money
opposing it.

> 3. Custodians don't get disproportionate voting power with their
customers' funds (not without getting themselves into fractional reserve,
at least).

I disagree. A. they already have fractional reserve most likely, but you're
right that it would cut into their normal rehypothication. But B.
custodians would definitely have an advantage because of holding people's
funds. They can use those funds however they want. If they think this vote
is more valuable to them then their normal rehypothication, they can direct
a lot of funds.

> 5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

This is a good point, and is something I missed above when I was talking
about coin-weighted polling. However, literally all signaling of any kind
is subject to this kind of thing, unless you do something like blind voting
(where the voter can't prove how they voted to a would be vote buyer). Not
sure how you'd do blind voting in a way people can trust. Then again, if
these things aren't actually voting, and its quite likely that people would
talk about any significant vote buying effort, its possible that such an
effort could be adjusted for.

On Thu, Apr 28, 2022 at 11:09 AM Billy Tetrud <billy.tetrud@gmail.com>
wrote:

> @Keagan
> > we have to have a way (formalized or not) of deciding when the "lesser
> experts" in aggregate have better judgement.
>
> I agree. Its certainly convenient for development speed to limit the
> number of cooks in the kitchen. But for the largest cryptocurrency in the
> world, we're going to have to face the reality that the number of
> stakeholders has grown vastly larger than the developer community and those
> who implicitly trust the developer community, or any particular part of the
> dev community working on any particular upgrade.
>
> > Perhaps it warrants zooming out beyond even what my proposal aims to
> solve
>
> I very much like the way you framed the question, and I think these are
> important, potentially existential questions we should urge the bitcoin
> community to think deeply about.
>
> > 1. ...  what would be the threshold for saying "this consensus change is
> ready for activation"?
>
> This is indeed the basic question.
>
> > 1a. Does that threshold change based on the nature of the consensus
> change
>
> I don't think the threshold of consensus changes should depend on the type
> of consensus change. Any consensus change, no matter how small, introduces
> risk, can cause bugs, can open a back door. Naturally, simpler changes
> should be able to *reach* consensus faster, because presumably it would
> take less analysis, and be easier to explain and convince people of. But
> that doesn't mean the bar of consensus should be lower. I think it should
> not. A change may look small and innocuous when it is in fact not, and it
> would be less than ideal for people to try to pretend there's sufficient
> consensus by insisting that a change is so "small" that no more is needed.
>
> > 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
> coordinators, layer2 protocols, miners) have a desired minimum or maximum
> representation in this "threshold"?
>
> There is a lot to say about this simple question. I think it should be
> recognized that the "say" anyone or any group has depends on their total
> future (or perhaps only total near-term) economic influence on the network.
> This is related to the concept of the "economic majority". What is the
> "economic majority"? We could say this depends exactly on the proportion of
> bitcoin you own, but I don't think that would be quite right. For example,
> a miner that (hypothetically) keeps no bitcoin except for what is being
> changed into fiat has an important role and significant economic influence
> on bitcoin. Miners provide a service. Their livelihood depends on
> bitcoiners, and the livelihood of bitcoin depends in part on miners.
> Similarly, a vendor who accepts bitcoin directly but converts it all to
> fiat provides a service as well. They expand the network of where bitcoin
> is directly useful. People willing to pay for things in bitcoin also
> similarly expand bitcoin's network.
>
> I think it only makes sense to align incentives and attempt to match the
> amount of representation a group gets to the amount of economic influence
> they have on the network. To do otherwise would invite a schism.
>
> Based on the above, I'm thinking that there are only really two components
> of what should comprise the weight of any person or group's say: 1. the
> stake they have in bitcoin, and 2. the value they provide to bitcoin. Let
> me elaborate:
>
> Bitcoin has a purpose. That purpose is as a currency. The directly
> valuable aspects of that are as a store of value and as a means of
> exchange. The properties of bitcoin lead to benefits to using it as both of
> those things. Therefore, the stake people have in holding bitcoin should
> count heavily because the value of holding is a major purpose of bitcoin.
> But at the same time the ability to transact bitcoin should also count
> pretty heavily because its also a major purpose of bitcoin and at the same
> time accepting or spending bitcoin expands the network. If we were able to
> economically equate those two things, we might get closer to a way to
> figure out how to ideally distribute representation. Similarly, we could
> add miners and developers into this mix, comparing them based on the value
> they provide to the network.
>
> So let:
> holdAmount = the value of bitcoin they're holding over a given period of
> time T
> transactionVolume = the volume of transaction value over a given period of
> time T
> miningVolume = the value of bitcoin they mined over time period T
> technologyValue = the value of new technological developments produced
> over time period T
>
> A group's representation should =
> (holdAmount*A + transactionVolume*B + miningVolume*C + technologyValue*D)
> /
> (totalLiveBitcoin*A + totalTransactionVolume*B + totalMiningVolume*C +
> totalTechnologyValue*D)
>
> where A through D are constants that relate the value of holding vs the
> value of transacting vs the value of mining vs the value of building
> bitcoin technology. We could split this up so that eg the representation
> that holders in total should have just by holding is: A/(A+B+C+D)
>
> For example, an equivalence could be: how much value does holding bitcoin
> give the average user per year? How much value does transacting give the
> average user per year? These are fuzzy and subjective and potentially
> dubious, but bare with me. Let's say that on average, a holder gets a
> benefit of 2% of their holdings per year (on a risk adjusted basis). That
> would be a benefit of $13.25 billion per year. And let's say that the ~$1.642
> trillion of transactions per year
> <https://data.nasdaq.com/data/BCHAIN/ETRVU-bitcoin-estimated-transaction-volume-usd> bitcoin
> is doing has about 33% being actual exchanges of goods and services
> <https://www.newsbtc.com/tech/only-33-of-bitcoin-payments-used-to-purchase-goods-economic-value-in-question/> and
> for that 33% the transactors in sum also get a benefit of about 2% of the
> transacted amount. That would be a benefit of $10.8 billion per year. If we
> proxy the value of bitcoin mining to the network as the revenue they
> received, perhaps this is as much as $15.3 billion
> <https://www.prnewswire.com/news-releases/bitcoin-miners-revenue-rose-206-in-2021-301482452.html#:~:text=The%20report%20finds%20that%20on,in%20terms%20of%20Bitcoin%20mining.>.
> How do we calculate the value of developers? I don't know a good proxy for
> that. But for kicks, why don't we say its as much as miners at $15.3
> billion.
>
> Using these numbers, the representation for each:
>
> Holders: 13.25/(13.25+10.8+15.3+15.3) = 24%
> Transactors: 10.8/(13.25+10.8+15.3+15.3) = 20%
> Miners:  15.3/(13.25+10.8+15.3+15.3) = 27%
> Developers: Also 27%
>
> Maybe we could approximate that as each of the four categories has a 1/4th
> share of representation. Values of A through D are certainly up for debate.
>
> In any case, to get back to the question at hand (1b), I don't see any
> reason to think there's a minimum or maximum representation for each
> primary constituency. However, there would of course be minimum and maximum
> bounds on our confidence for how much value/stake each constituency has,
> and therefore a confidence range on how much representation they should
> have.
>
> But this 4 part group of holders, transactors, miners, and developers
> seems to make a lot of sense to me. These are the main groups, and any
> other subgroup can neatly fit into one or more of those.
>
> With the assumption that the above numbers are somewhat accurate, it seems
> reasonable to say that any majority of those four groups should be able to
> prevent a change from happening. Maybe even any 40% of any of those groups.
> Were we to roll this all into a single count, 40% of any group of 25% of
> the whole is 10%, so it kind of supports the idea of a 90% threshold.
> Although of course right now we have a 90% threshold on just miner
> signaling. But since that's the only direct signaling we have, I think we
> prudently erred on the safe side. But perhaps if we have something near
> 100% consensus in support of a change among the other 3 categories, perhaps
> we could safely reduce the miner signaling quite a bit, perhaps not to 60%
> (because of chain split concerns) but perhaps to 70% or 75%.
>
> > what tests can we devise to measure those levels of support directly? If
> we can't measure it directly, can we measure different indicators that
> would help us infer or solve for the knowledge we want?
>
> For 3 of the 4 groups, there seems to me clear mechanisms we can use:
> * Holders: Something akin to my coin-weighted polling proposal here
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>
> .
> * Transactors: Something akin to your transaction signaling proposal
> above. Tho I would strongly suggest removing the tie between miner
> signaling and transaction signaling to make it purely informational.
> * Miner signaling as usual, or perhaps extended to provide a way for
> miners to actively signal against a change
> <https://github.com/fresheneesz/bip-trinary-version-signaling>.
>
> For developers, I would say we probably need to come to consensus with
> discussion, but hopefully we could be a bit more structured about it. For
> example, we could get rough measures of consensus by gathering explicit
> reviews on a proposal. Opinions like "I don't like it" or "This is great,
> let's do it!" would count for very little, reviews that look into a
> particular section deeply or review the broad idea as a whole would count a
> bit more, and reviews that discuss many good points and reasons about a
> large fraction of the proposal would carry even more weight. This is of
> course again subjective, but at least it would provide a framework to work
> within, and a way to at least approximate a developer consensus weighted by
> actual knowledge of and thought put into the subject. If we went further to
> attempt to collect together these reviews in a structured way, it would
> make it easier for someone to relatively quickly (ie by spending a few
> hours reading through reviews) verify for themselves approximately what
> consensus "is".
>
> > 3. Can any of the answers to #2 be "gamed"?
>
> As long as we understand the limitations of the measurements, I don't
> think they can be gamed. However, they can leave a lot of room for doubt.
> Eg, a coin-weighted poll might only have a response rate of 5% of the coin.
> If we allow signals to both support or oppose a change, I think that would
> substantially increase the meaningfulness of the data - at least we know
> the consensus among those who care / are aware enough to signal (without
> allowing opposition signaling, a low response rate means we have no idea
> how many of the non signalers oppose a thing).
>
> The transaction signaling can be gamed a bit, because someone can simply
> spend more money to send more signals. This might favor bad actors a bit
> (honest actors presumably wouldn't attempt to game the system).
>
> Miner signaling doesn't really seem gameable.
>
> TBH, developer consensus is probably the most gameable. All it is is talk.
> Putting coin weight behind it would bias things, and often the
> loudest/frequentest talkers get an advantage. Putting some major thought
> into how to de-bias developer consensus seems like the most important thing
> to figure out.
>
> > Perhaps .. we are doomed to this painful process of arguing .. until
> there's only one opinion left standing.. However, if this is the case, I
> don't think we can honestly claim that devs don't control the protocol.
>
> If we argue until the last left standing, is it even "the developers" in
> control? Might it rather be the talkers, the yellers, the busy bodies? I
> can't think of anyone worse being in control. I very much hope we're not
> doomed to that fate. However, to avoid it, we need to come up with a
> logical solution that is defendable and encodable into the social fabric of
> bitcoin (just like sound money and nacho keys nacho cheese).
>
> On Thu, Apr 28, 2022 at 12:18 AM Billy Tetrud <billy.tetrud@gmail.com>
> wrote:
>
>>   @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.
>>>
>>>

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

<div dir=3D"ltr">@Zman<br><div>&gt; if two people are perfectly rational an=
d start from the same information, they *will* agree</div><div><br></div><d=
iv>I take issue with this. I view the word &quot;rational&quot; to mean bas=
ically logical. Someone is rational if they advocate for things that are be=
st for them. Two humans are not the same people. They have different circum=
stances and as a result different goals. Two actors with different goals wi=
ll inevitably have things they rationally and logically disagree about. The=
re is no universal rationality. Even an AI from outside space and time is i=
ncredibly likely to experience at least some value drift from its peers.=C2=
=A0</div><div><br></div><div>&gt; 3.=C2=A0 Can we actually have the goals o=
f all humans discussing this topic all laid out, *accurately*?</div><div><b=
r></div><div>I think this would be a very useful exercise=C2=A0to do on a r=
egular basis. This conversation is a good example, but conversations like t=
his are rare. I tried to discuss <a href=3D"https://github.com/fresheneesz/=
bitcoinThroughputAnalysis#general-goals">some goals</a> we might want bitco=
in to have in a paper I wrote about throughput bottlenecks. Coming to a con=
sensus around goals, or at very least identifying various competing groupin=
gs of goals would be quite useful to streamline conversations and to more e=
ffectively share ideas.=C2=A0</div><div><br></div><div>@Nadav<br></div><div=
>&gt; 1. There&#39;s a real cost attached to voting</div><div><br></div><di=
v>This is IMO a huge downside. It prevents many from participating at all. =
And it also give a big advantage to those who have a large monetary consequ=
ence. It exacerbates the common problem in votes where special interests sp=
end lots of time and money to get something passed that is bad overall, whi=
le its not bad enough for most people to spend time and money opposing it.=
=C2=A0</div><div><br></div><div>&gt; 3. Custodians don&#39;t get disproport=
ionate voting power with their customers&#39; funds (not without getting th=
emselves into fractional reserve, at least).</div><div><br></div><div>I dis=
agree. A. they already have fractional reserve most likely, but you&#39;re =
right that it would cut into their normal rehypothication. But B. custodian=
s would definitely have an advantage because of holding people&#39;s funds.=
 They can use those funds however they want. If they think this vote is mor=
e valuable to them then their normal rehypothication, they can direct a lot=
 of funds.=C2=A0</div><div><br></div><div>&gt; 5. Selling your vote if you&=
#39;re disinterested in the outcome isn&#39;t a no-brainer like in the naiv=
e scheme.<br></div><div><br></div><div>This is a good point, and is somethi=
ng I missed above when I was talking about coin-weighted polling. However, =
literally all signaling of any kind is subject to this kind of thing, unles=
s you do something like blind voting (where the voter can&#39;t prove how t=
hey voted to a would be vote buyer). Not sure how you&#39;d do blind voting=
 in a way people can trust. Then again, if these things aren&#39;t actually=
 voting, and its quite likely that people would talk about any significant =
vote buying effort, its possible that such an effort could be adjusted for.=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Thu, Apr 28, 2022 at 11:09 AM Billy Tetrud &lt;<a href=3D"mailto:b=
illy.tetrud@gmail.com">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote 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><div><sp=
an style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">@Keaga=
n<br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,he=
lvetica,sans-serif">&gt;=C2=A0</span><span style=3D"color:rgb(0,0,0);font-f=
amily:arial,helvetica,sans-serif">we have to have a way (formalized or not)=
 of deciding when the &quot;lesser experts&quot; in aggregate have better j=
udgement.</span></div><div><span style=3D"color:rgb(0,0,0);font-family:aria=
l,helvetica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,=
0);font-family:arial,helvetica,sans-serif">I agree. Its certainly convenien=
t for development speed to limit the number of cooks in the kitchen. But fo=
r the largest cryptocurrency in the world, we&#39;re going to have to face =
the reality that the number of stakeholders has grown vastly larger than th=
e developer community and those who implicitly trust the developer communit=
y, or any particular part of the dev community working on any particular up=
grade.=C2=A0</span></div><div><span style=3D"color:rgb(0,0,0);font-family:a=
rial,helvetica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0=
,0,0);font-family:arial,helvetica,sans-serif">&gt;=C2=A0</span>Perhaps it w=
arrants zooming out beyond even what my proposal aims to solve</div><div><b=
r></div><div>I very much like the way you framed the question, and I think =
these are important, potentially existential questions we should urge the b=
itcoin community to think deeply about.=C2=A0</div><div><br></div><div>&gt;=
 1. ...=C2=A0 what would be the threshold for saying &quot;this consensus c=
hange is ready for activation&quot;?</div><div><br></div><div>This is indee=
d the basic question.=C2=A0</div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D"col=
or:rgb(0,0,0);font-family:arial,helvetica,sans-serif">&gt;=C2=A0</span>1a. =
Does that threshold change based on the nature of the consensus change</div=
><div><br></div><div>I don&#39;t think the threshold of consensus changes s=
hould depend on the type of consensus change. Any consensus change, no matt=
er how small, introduces risk, can cause bugs, can open a back door. Natura=
lly, simpler changes should be able to *reach* consensus faster, because pr=
esumably it would take less analysis, and be easier to explain and convince=
 people of. But that doesn&#39;t mean the bar of consensus should be lower.=
 I think it should not. A change may look small and innocuous=C2=A0when it =
is in fact not, and it would be less than ideal for people to try to preten=
d there&#39;s sufficient consensus by insisting that a change is so &quot;s=
mall&quot; that no more is needed.</div><div><br></div><div>&gt; 1b. Do dif=
ferent constituencies (end users, wallets, exchanges, coinjoin coordinators=
, layer2 protocols, miners) have a desired minimum or maximum representatio=
n in this &quot;threshold&quot;?</div><div><br></div><div>There is a lot to=
 say about this simple question. I think it should be recognized that the &=
quot;say&quot; anyone or any group has depends on their total future (or pe=
rhaps only total near-term) economic influence on the network. This is rela=
ted to the concept of the &quot;economic majority&quot;. What is the &quot;=
economic majority&quot;?=C2=A0We could say this depends exactly on the prop=
ortion of bitcoin you own, but I don&#39;t think that would be quite right.=
 For example, a miner that (hypothetically) keeps no bitcoin except for wha=
t is being changed into fiat has an important role and significant economic=
 influence on bitcoin. Miners provide a service. Their livelihood depends o=
n bitcoiners, and the livelihood of bitcoin depends in part on miners. Simi=
larly, a vendor who accepts bitcoin directly but converts it all to fiat pr=
ovides a service as well. They expand the network of where bitcoin is direc=
tly useful. People willing to pay for things in bitcoin also similarly expa=
nd bitcoin&#39;s network.=C2=A0</div><div><span style=3D"color:rgb(0,0,0);f=
ont-family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">I think it only m=
akes sense to align incentives and attempt to match the amount of represent=
ation a group gets to the amount of economic influence they have on the net=
work. To do otherwise would invite a schism.=C2=A0</span></div><div><span s=
tyle=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span=
></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">B=
ased on the above, I&#39;m thinking that there are only really two componen=
ts of what should comprise the weight of any person or group&#39;s say: 1. =
the stake they have in bitcoin, and 2. the value they provide to bitcoin. L=
et me elaborate:</font></div><div><font color=3D"#000000" face=3D"arial, he=
lvetica, sans-serif"><br></font></div><div><font color=3D"#000000" face=3D"=
arial, helvetica, sans-serif">Bitcoin has a purpose. That purpose is as a c=
urrency. The directly valuable aspects of that are as a store of value and =
as a means of exchange. The properties of bitcoin lead to benefits to using=
 it as both of those things. Therefore, the stake people have in holding bi=
tcoin should count heavily because the value of holding is a major purpose =
of bitcoin. But at the same time the ability to transact bitcoin should als=
o count pretty heavily because its also a major purpose of bitcoin and at t=
he same time accepting or spending bitcoin expands the network. If we were =
able to economically equate those two things, we might get closer to a way =
to figure out how to ideally distribute representation. Similarly, we could=
 add miners and developers into this mix, comparing them based on the value=
 they provide to the network.=C2=A0</font></div><div><font color=3D"#000000=
" face=3D"arial, helvetica, sans-serif"><br></font></div><div><font color=
=3D"#000000" face=3D"arial, helvetica, sans-serif">So let:</font></div><div=
><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">holdAmount =
=3D the=C2=A0</font><span style=3D"color:rgb(0,0,0);font-family:arial,helve=
tica,sans-serif">value of bitcoin they&#39;re holding over a given period o=
f time T</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial=
,helvetica,sans-serif">transactionVolume =3D the volume of transaction valu=
e over a given period of time T</span></div><div><span style=3D"color:rgb(0=
,0,0);font-family:arial,helvetica,sans-serif">miningVolume =3D the value of=
 bitcoin they mined over time period T</span></div><div><span style=3D"colo=
r:rgb(0,0,0);font-family:arial,helvetica,sans-serif">technologyValue =3D th=
e value of new technological developments produced over time period T</span=
></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><=
br></font></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans=
-serif">A group&#39;s representation should =3D=C2=A0</font></div><div><fon=
t color=3D"#000000" face=3D"arial, helvetica, sans-serif">(holdAmount*A=C2=
=A0+ transactionVolume*B + miningVolume*C + technologyValue*D)</font></div>=
<div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">/</font>=
</div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">(t=
otalLiveBitcoin*A + totalTransactionVolume*B</font><span style=3D"color:rgb=
(0,0,0);font-family:arial,helvetica,sans-serif">=C2=A0</span><span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">+ totalMiningVolu=
me*C + totalTechnologyValue*D</span><span style=3D"color:rgb(0,0,0);font-fa=
mily:arial,helvetica,sans-serif">)</span></div><div><font color=3D"#000000"=
 face=3D"arial, helvetica, sans-serif"><br></font></div><div><font color=3D=
"#000000" face=3D"arial, helvetica, sans-serif">where A through D are const=
ants that relate the value of holding vs the value of transacting vs the va=
lue of mining vs the value of building bitcoin technology. We could split t=
his up so that eg the representation that holders in total should have just=
 by holding is: A/(A+B+C+D)</font></div><div><div><font color=3D"#000000" f=
ace=3D"arial, helvetica, sans-serif"></font></div><div><font color=3D"#0000=
00" face=3D"arial, helvetica, sans-serif"><br></font></div><div><font color=
=3D"#000000" face=3D"arial, helvetica, sans-serif">For example, an equivale=
nce could be: how much value does holding bitcoin give the average user per=
 year? How much value does transacting give the average user per year? Thes=
e are fuzzy and subjective and potentially dubious, but bare with me. Let&#=
39;s say that on average, a holder gets a benefit of 2% of their holdings p=
er year (on a risk adjusted basis). That would be a benefit of $13.25 billi=
on per year. And let&#39;s say that the <a href=3D"https://data.nasdaq.com/=
data/BCHAIN/ETRVU-bitcoin-estimated-transaction-volume-usd" target=3D"_blan=
k">~$1.642 trillion of transactions per year</a>=C2=A0bitcoin is doing has =
about <a href=3D"https://www.newsbtc.com/tech/only-33-of-bitcoin-payments-u=
sed-to-purchase-goods-economic-value-in-question/" target=3D"_blank">33% be=
ing actual exchanges of goods and services</a>=C2=A0and for that 33% the tr=
ansactors in sum also get a benefit of about 2% of the transacted amount. T=
hat would be a benefit of $10.8 billion per year. If we proxy the value of =
bitcoin mining to the network as the revenue they received, perhaps this is=
 as much as <a href=3D"https://www.prnewswire.com/news-releases/bitcoin-min=
ers-revenue-rose-206-in-2021-301482452.html#:~:text=3DThe%20report%20finds%=
20that%20on,in%20terms%20of%20Bitcoin%20mining." target=3D"_blank">$15.3 bi=
llion</a>. How do we calculate the value of developers? I don&#39;t know a =
good proxy for that. But for kicks, why don&#39;t we say its as much as min=
ers at $15.3 billion.</font></div></div><div><font color=3D"#000000" face=
=3D"arial, helvetica, sans-serif"><br></font></div><div><font color=3D"#000=
000" face=3D"arial, helvetica, sans-serif">Using these numbers, the represe=
ntation for each:</font></div><div><font color=3D"#000000" face=3D"arial, h=
elvetica, sans-serif"><br></font></div><div><font color=3D"#000000" face=3D=
"arial, helvetica, sans-serif">Holders:=C2=A0</font>13.25/<font color=3D"#0=
00000" face=3D"arial, helvetica, sans-serif">(</font>13.25+10.8+15.3+15.3) =
=3D 24%</div><div>Transactors:=C2=A010.8/<font color=3D"#000000" face=3D"ar=
ial, helvetica, sans-serif">(</font>13.25+10.8+15.3+15.3) =3D 20%</div><div=
>Miners:=C2=A0

15.3/<font color=3D"#000000" face=3D"arial, helvetica, sans-serif">(</font>=
13.25+10.8+15.3+15.3) =3D 27%</div><div>Developers: Also 27%</div><div><br>=
</div><div>Maybe we could approximate that as each of the four categories h=
as a 1/4th share of representation. Values of A through D are certainly up =
for debate.</div><div><br></div><div>In any case, to get back to the questi=
on at hand (1b), I don&#39;t see any reason to think there&#39;s a minimum =
or maximum representation for each primary constituency. However, there wou=
ld of course be minimum and maximum bounds on our confidence for how much v=
alue/stake each constituency has, and therefore a confidence range on how m=
uch representation they should have.=C2=A0</div><div><br></div><div>But thi=
s 4 part group of holders, transactors, miners, and developers seems to mak=
e a lot of sense to me. These are the main groups, and any other subgroup c=
an neatly fit into one or more of those.</div></div><div><br></div><div>Wit=
h the assumption that the above numbers are somewhat accurate, it seems rea=
sonable to say that any majority of those four groups should be able to pre=
vent a change from happening. Maybe even any 40% of any of those groups. We=
re we to roll this all into a single count, 40% of any group of 25% of the =
whole is 10%, so it kind of supports the idea of a 90% threshold. Although =
of course right now we have a 90% threshold on just miner signaling. But si=
nce that&#39;s the only direct signaling we have, I think we prudently erre=
d on the safe side. But perhaps if we have something near 100% consensus in=
 support of a change among the other 3 categories, perhaps we could safely =
reduce the miner signaling quite a bit, perhaps not to 60% (because of chai=
n split concerns) but perhaps to 70% or 75%.=C2=A0=C2=A0</div><div><br></di=
v><div>&gt; what tests can we devise to measure those levels of support dir=
ectly? If we can&#39;t measure it directly, can we measure different indica=
tors that would help us infer or solve for the knowledge we want?</div><div=
><br></div><div>For 3 of the 4 groups, there seems to me clear mechanisms w=
e can use:=C2=A0</div><div>* Holders: Something akin to my=C2=A0<a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.h=
tml" target=3D"_blank">coin-weighted polling proposal here</a>.</div><div>*=
 Transactors: Something akin to your transaction signaling proposal above. =
Tho I would strongly suggest removing the tie between miner signaling and t=
ransaction signaling to make it purely informational.</div><div>* Miner sig=
naling as usual, or perhaps extended to provide a way for miners to <a href=
=3D"https://github.com/fresheneesz/bip-trinary-version-signaling" target=3D=
"_blank">actively signal against a change</a>.</div><div><br></div><div>For=
 developers, I would say we probably need to come to consensus with discuss=
ion, but hopefully we could be a bit more structured about it. For example,=
 we could get rough measures of consensus by gathering explicit reviews on =
a proposal. Opinions like &quot;I don&#39;t like it&quot; or &quot;This is =
great, let&#39;s do it!&quot; would count for very little, reviews that loo=
k into a particular section deeply or review the broad idea as a whole woul=
d count a bit more, and reviews that discuss many good points and reasons a=
bout a large fraction of the proposal would carry even more weight. This is=
 of course again subjective, but at least it would provide a framework to w=
ork within, and a way to at least approximate a developer consensus weighte=
d by actual knowledge of and thought put into the subject. If we went furth=
er to attempt to collect together these reviews in a structured way, it wou=
ld make it easier for someone to relatively quickly (ie by spending a few h=
ours reading through reviews) verify for themselves approximately what cons=
ensus &quot;is&quot;.=C2=A0</div><div><br></div><div>&gt; 3. Can any of the=
 answers to #2 be &quot;gamed&quot;?</div><div><br></div><div>As long as we=
 understand the limitations of the measurements, I don&#39;t think they can=
 be gamed. However, they can leave a lot of room for doubt. Eg, a coin-weig=
hted poll might only have a response rate of 5% of the coin. If we allow si=
gnals to both support or oppose a change, I think that would substantially =
increase the meaningfulness of the data - at least we know the consensus am=
ong those who care / are aware enough to signal (without allowing oppositio=
n signaling, a low response rate means we have no idea how many of the non =
signalers oppose a thing).=C2=A0</div><div><br></div><div>The transaction s=
ignaling can be gamed a bit, because someone can simply spend more money to=
 send more signals. This might favor bad actors a bit (honest actors presum=
ably wouldn&#39;t attempt to game the system).=C2=A0</div><div><br></div><d=
iv>Miner signaling doesn&#39;t really seem gameable.</div><div><br></div><d=
iv>TBH, developer consensus is probably the most gameable. All it is is tal=
k. Putting coin weight behind it would bias things, and often the loudest/f=
requentest=C2=A0talkers get an advantage. Putting some major thought into h=
ow to de-bias developer consensus seems like the most important thing to fi=
gure out.=C2=A0</div><div><br></div><div>&gt; Perhaps .. we are doomed to t=
his painful process of arguing .. until there&#39;s=C2=A0only one opinion l=
eft standing.. However, if this is the case, I don&#39;t think we can hones=
tly claim that devs don&#39;t control the protocol.</div><div><br></div><di=
v>If we argue until the last left standing, is it even &quot;the developers=
&quot; in control? Might it rather be the talkers, the yellers, the busy bo=
dies? I can&#39;t think of anyone worse being in control. I very much hope =
we&#39;re not doomed to that fate. However, to avoid it, we need to come up=
 with a logical solution that is defendable and encodable into the social f=
abric of bitcoin (just like sound money and nacho keys nacho cheese).</div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu, Apr 28, 2022 at 12:18 AM Billy Tetrud &lt;<a href=3D"mailto:billy.t=
etrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br=
></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>=C2=A0 @Felipe<br><div>&gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-f=
amily:arial,helvetica,sans-serif">the consensus should follow the current l=
ine: discussions and tests carried out by experts. We all know that the mos=
t 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:ari=
al,helvetica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0=
,0);font-family:arial,helvetica,sans-serif">We have up til this point been =
miraculously lucky that the vast majority of prominent=C2=A0bitcoin develop=
ers are in relative alignment on the big picture philosophy and have all se=
emed 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 enor=
mous attack vector. It should not be the &quot;most important&quot; devs wh=
o 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=C2=A0Keagan&#39;s implication that this is not how bitcoin=
 should govern itself. We should move away from appeals to authority toward=
s something more amorphous and difficult to control.</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">@Jeremy<br>&gt;=C2=A0</span><span style=3D"color:rgb(0,0,0);font=
-family:arial,helvetica,sans-serif">if there were a way to sign with a NUMS=
 point for ring signature purposes</span></div><div><span style=3D"color:rg=
b(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">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 signa=
led in what direction?=C2=A0</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">&gt;=C2=A0</s=
pan><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"=
>if NUMS points are common these ring signatures protocols might not be too=
 useful for collecting signals=C2=A0</span></div><div><span style=3D"color:=
rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><s=
pan 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 pr=
operties increasing as the privacy technique used becomes more common.</spa=
n></div><div></div></div><div><span style=3D"color:rgb(0,0,0);font-family:a=
rial,helvetica,sans-serif"><br></span></div><div>@Erik<br></div><div>&gt; i=
t 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 nonexperts can &quot;h=
ave 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 about this is in ter=
ms 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 subje=
ctive and therefore there is no &quot;best&quot; technical solution all the=
 time. Sometimes the preferences of stakeholders must be weighed and a comp=
romise=C2=A0come to. Hopefully most of these kinds of compromises can happe=
n 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 expert with deep kno=
wledge can deeply understand a design or change well enough to come to a fu=
ll opinion about it according to their preferences. But even other experts =
might not have read enough about a thing, or just don&#39;t have time to de=
lve deeply into that particular aspect. They&#39;ll have to rely partly on =
their ability to make a determination from partial knowledge and their abil=
ity to evaluate the trustworthiness and skill of those who have deeper know=
ledge than them. Nonexperts=C2=A0and non-technical people have to rely on t=
hose 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><div><br></div><div>=
I believe that the truth gets out eventually. Those who have deep knowledge=
 will eventually convince those who don&#39;t, tho that may take a long tim=
e 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 co=
nsensus. 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 make clearly enough =
that a certainly level of comfort diffuses into the social circles of peopl=
e who care about bitcoin but don&#39;t understand it at a technical enough =
level to participate in technical decision making. At a certain point, if n=
ot enough people are comfortable with a change, the change 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 be a glue that conn=
ects together otherwise unconnected pockets of wisdom.=C2=A0</div><div><br>=
</div><div>Doing things this way would almost certainly lead to slower deve=
lopment. But development of the consensus layer slowing over time should be=
 what we all expect, and I daresay what we should all want eventually.=C2=
=A0</div><div><br></div><div>&gt; it will just be a poll of &quot;people wh=
o pay attention to the dev list and maybe some irc rooms&quot;<br></div><di=
v><br></div><div>Maybe. But if there were mechanisms for broader consensus =
measuring, perhaps more would pay attention. Perhaps some way to affect cha=
nge would lead more to have discussions and participate.=C2=A0</div><div><b=
r></div><div>Even if its a small group at first, I think it would be very u=
seful information to see both who explicitly supports something, who explic=
itly is against something, and also who is paying attention but neutral (ma=
ybe even actively signaling as &quot;neutral&#39;).</div><div><br></div><di=
v>&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 agre=
e. Tooling would be very important here.</div><div><br></div><div><span sty=
le=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span><=
/div><div><br></div><div><br></div><div><br></div><div><span style=3D"color=
:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed=
, Apr 27, 2022 at 3:13 PM Erik Aronesty &lt;<a href=3D"mailto:erik@q32.com"=
 target=3D"_blank">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 rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left: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.linuxfo=
undation.org/pipermail/bitcoin-dev/2022-March/020146.html" target=3D"_blank=
">my proposal</a>? The proposal is, to be clear, *not* &quot;voting&quot; b=
ut rather polling that isn&#39;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 cons=
ensus gathering.=C2=A0</div></div></blockquote><div><br></div><div>it&#39;s=
 cool, 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;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>Let&#39;s say everyone who participates in polling broadcasts it along th=
e bitcoin network (a separate network would probably be better, so as to no=
t interfere with normal bitcoin, but I digress), </div></div></blockquote><=
div><br></div><div>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<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>Similar structures could be add=
ed to any script configuration to allow signing of polls without any signif=
icant exposure.<br></div></div></blockquote><div><div><br></div>rubin&#39;s=
 suggestion 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 does=
n&#39;t address the &quot;what about people who don&#39;t know there&#39;s =
a vote going on&quot;=C2=A0 or other the other social issues with &quot;wei=
ghted polling&quot; in general, like how nonexperts can &quot;have a say&qu=
ot; when they simply don&#39;t understand the relevant issues.=C2=A0 i pers=
onally feel like i&#39;m &quot;only a very little bit up on the issues&quot=
; and i have more tech knowledge than most people i know<br><br>also, it wi=
ll just be a poll of &quot;people who pay attention to the dev list and may=
be some irc rooms&quot;<br></div></div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote"><div>might be worth experimenting with... but u=
nless 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, s=
imple cli, gitian build, installs easily on all platforms, works well with =
bitcoind 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>
</blockquote></div>
</blockquote></div>

--000000000000cddd8605ddb98487--