@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 bitcoin is doing has about 33% being actual exchanges of goods and services 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. 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:
* 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.
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).