From: Billy Tetrud <billy.tetrud@gmail•com>
To: Erik Aronesty <erik@q32•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks
Date: Thu, 28 Apr 2022 11:09:36 -0500 [thread overview]
Message-ID: <CAGpPWDaBcZfH=EhoSbsQHp5nKkJZheMPXudDkDjWX56n9PGB_A@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDZ_3gffJsdofpLQDg5F6Qg03G+5897SJENQEhVv0d-jrg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 18675 bytes --]
@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.
>>
>>
[-- Attachment #2: Type: text/html, Size: 26172 bytes --]
next prev parent reply other threads:[~2022-04-28 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 19:37 Keagan McClelland
2022-04-26 20:39 ` Bryan Bishop
2022-04-27 3:04 ` Billy Tetrud
2022-04-27 14:01 ` Chris Riley
2022-04-27 14:28 ` Erik Aronesty
2022-04-27 16:17 ` Billy Tetrud
2022-04-27 20:13 ` Erik Aronesty
2022-04-28 5:18 ` Billy Tetrud
2022-04-28 16:09 ` Billy Tetrud [this message]
2022-04-28 16:35 ` Billy Tetrud
2022-04-30 6:14 ` ZmnSCPxj
2022-05-01 22:41 ` Billy Tetrud
2022-04-27 15:27 ` Ryan Grant
2022-04-27 17:22 ` micaroni
2022-04-27 18:32 ` Keagan McClelland
2022-04-28 5:26 ` ZmnSCPxj
2022-04-28 8:03 ` micaroni
2022-04-27 17:54 ` Jeremy Rubin
2022-04-28 0:16 ` Nadav Ivgi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGpPWDaBcZfH=EhoSbsQHp5nKkJZheMPXudDkDjWX56n9PGB_A@mail.gmail.com' \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox