There are many challenges with on-chain voting, here are a few: - We may not want votes on-chain, because it creates miner incentives for contentious BIP's to drive up fees - Miners can block votes from the chain - Cold storage votes are probably the most important for certain proposals (like vaulting), but are the least-likely to vote - Awareness and participation in blockchain voting is typically very low and is mostly limited to big exchanges
And off chain voting is even worse: - We can collect votes off-chain by signing messages and publishing them "somewhere", but where would that be? - How do you make this censorship-resistant? - Suppose someone's coins are protected by a hot/cold covenant, like TLUV or CTV: parse scripts? Ick. Although I do wish sometimes that this were not the case, I feel like the verbal wrangling and rough/messy-consensus building remains our best choice. On Wed, Apr 27, 2022 at 10:07 AM Chris Riley via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >> we should not let the wealthy make consensus decisions. > > >We shouldn't let the wealthy continue to control our governments. > However, bitcoin is not a government. Its a financial network. > >The fact of the matter is that fundamentally, the economic majority > controls where the chain goes. Its very likely that the wealthy > >are disproportionately represented in the economic majority. Attempting > to subvert the economic majority seems like a bad idea. > >The reality of control there will come out one way or another, and being > honest about it is probably the best way to avoid major schisms in the > future. > > Yes, the economic majority is important: Who else has more incentive to > protect the security and thus the value embodied in the network than people > who have invested money and time in the network? A group of people with > 1/10/100/1000 bitcoins each has more economic incentive to do so than a > similar sized group with 1/10/100/1000 satoshis each. Likewise, it is > significantly easier to mobilize 1 million people "voting" with 100 > satoshis each - a total of 1 BTC - vs 10000 people each voting with 100 > bitcoins each - a total of 1 million BTC. I don't think anyone would say > that even if those 1 million people, for example, thought that we should > increase the number of bitcoins via perpetual inflation it would be a good > idea to listen to it however the vote was done whether via transaction > flags or something else. Of course they could fork off. > > Cheers, :-) > Chris > > > > > > On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > A transaction signaling in the affirmative MUST NOT be included in a >> block that does not signal in the affirmative >> >> I feel like I've heard this idea somewhere before. Its an interesting >> idea. >> >> It should be noted that there is a consequence of this: holders wouldn't >> have much say. People that transact a lot (or happen to be transacting a >> lot during the signaling time period) would have a very disproportionate >> ability to pressure miners than people who aren't transacting much. This >> would probably be a pretty good proxy for future mining revenue that >> supports (or is against) a particular thing. However, the network does do >> more than just transact, so I would be a bit worried that such a mechanism >> would bias the system towards things that are good for transactors and bad >> for holders. Things like more coin inflation, larger blocks, etc. >> >> Another consideration is that miners are already incentivized to follow >> the money here. Adding an *additional* incentive might be distorting the >> market, so to speak. >> >> An alternative I proposed was a way to do weighted polling of holders: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html >> >> The polling wouldn't be directly connected to the activation mechanism in >> any way, but would just be a mechanism to gauge some portion of consensus. >> If enough people were involved, theoretically it could be hooked up to >> activation, but I would be pretty wary of doing that directly as well. >> >> > we should not let the wealthy make consensus decisions. >> >> We shouldn't let the wealthy continue to control our governments. >> However, bitcoin is not a government. Its a financial network. The fact of >> the matter is that fundamentally, the economic majority controls where the >> chain goes. Its very likely that the wealthy are disproportionately >> represented in the economic majority. Attempting to subvert the economic >> majority seems like a bad idea. The reality of control there will come out >> one way or another, and being honest about it is probably the best way to >> avoid major schisms in the future. >> >> > Does a scheme like this afford us a better view into consensus than we >> have today? >> >> It does more than provide a view. It directly changes the game theory >> around how activation works. If we wanted to simply get a better view into >> consensus, we could allow the same thing, but allow any block to mine any >> transaction regardless of transaction signaling. Then it would be more >> purely informational. >> >> > Can it be gamed to give us a *worse* view into consensus? How? >> > Does it measure the right thing? If not, what do you think is the right >> thing to measure? >> >> Doesn't seem like it could be gamed, but as I mentioned above, the honest >> mechanics of it might be themselves undesirably distorting. >> >> >> >> On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> You may be interested in these posts on transaction signalling: >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html >>> >>> >>> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> Hi all, >>>> >>>> Alongside the debate with CTV right now there's a second debate that >>>> was not fully hashed out in the activation of Taproot. There is a lot of >>>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't >>>> etc. A significant reason for the breakdown in civility around this debate >>>> is that because we don't have a means of measuring user support for >>>> proposed sof-fork changes, it invariably devolves into people claiming that >>>> their circles support/reject a proposal, AND that their circles are more >>>> broadly representative of the set of Bitcoin users as a whole. >>>> >>>> It seems everyone in this forum has at one point or another said "I >>>> would support activation of ____ if there was consensus on it, but there >>>> isn't". This statement, in order to be true, requires that there exist a >>>> set of conditions that would convince you that there is consensus. People >>>> have tried to dodge this question by saying "it's obvious", but the reality >>>> is that it fundamentally isn't. My bubble has a different "obvious" answer >>>> than any of yours. >>>> >>>> Secondly, due to the trauma of the block size wars, no one wants to >>>> utter a statement that could imply that miners have any influence over what >>>> rulesets get activated or don't. As such "miner signaling" is consistently >>>> devalued as a signal for market demand. I don't think this is reasonable >>>> since following the events of '17 miners are aware that they have the >>>> strong incentive that they understand market demand. Nevertheless, as it >>>> stands right now the only signal we have to work with is miner signaling, >>>> which I think is rightly frustrating to a lot of people. >>>> >>>> So how can we measure User Support for a proposed rule change? >>>> >>>> I've had this idea floating around in the back of my head for a while, >>>> and I'd like to solicit some feedback here. Currently, all forms of >>>> activation that are under consideration involve miner signaling in one form >>>> or another. What if we could make it such that users could more directly >>>> pressure miners to act on their behalf? After all, if miners are but the >>>> humble servants of user demands, this should be in alignment with how >>>> people want Bitcoin to behave. >>>> >>>> Currently, the only means users have of influencing miner decisions are >>>> A. rejection of blocks that don't follow rules and B. paying fees for >>>> transaction inclusion. I suggest we combine these in such a way that >>>> transactions themselves can signal for upgrade. I believe (though am not >>>> certain) that there are "free" bits in the version field of a transaction >>>> that are presently ignored. If we could devise a mapping between some of >>>> those free bits, and the signaling bits in the block header, it would be >>>> possible to have rules as follows: >>>> >>>> - A transaction signaling in the affirmative MUST NOT be included in a >>>> block that does not signal in the affirmative >>>> - A transaction that is NOT signaling MAY be included in a block >>>> regardless of that block's signaling vector >>>> - (Optional) A transaction signaling in the negative MUST NOT be >>>> included in a block that signals in the affirmative >>>> >>>> Under this set of conditions, a user has the means of sybil-resistant >>>> influence over miner decisions. If a miner cannot collect the fees for a >>>> transaction without signaling, the user's fee becomes active economic >>>> pressure for the miner to signal (or not, if we include some variant of the >>>> negative clause). In this environment, miners could have a better view into >>>> what users do want, as would the Bitcoin network at large. >>>> >>>> Some may take issue with the idea that people can pay for the outcome >>>> they want and may try to compare a method like this to Proof of Stake, but >>>> there are only 3 sybil resistant mechanisms I am aware of, and any "real" >>>> view into what social consensus looks like MUST be sybil resistant: >>>> >>>> - Hashpower >>>> - Proof of personhood (KYC) >>>> - Capital burn/risk >>>> >>>> Letting hashpower decide this is the thing that is currently >>>> contentious, KYC is dead on arrival both on technical and social grounds, >>>> which really just leaves some means of getting capital into the process of >>>> consensus measurement. This mechanism I'm proposing is measurable >>>> completely en-protocol and doesn't require trust in institutions that fork >>>> futures would. Additionally it could be an auxiliary feature of the soft >>>> fork deployment scheme chosen making it something you could neatly package >>>> all together with the deployment itself. >>>> >>>> There are many potential tweaks to the design I propose above: >>>> 1. Do we include a notion of negative signaling (allowing for the >>>> possibility of rejection) >>>> 2. Do we make it such that miner signaling must be congruent with >X% >>>> of transactions, where congruence is that the signal must match any >>>> non-neutral signal of transaction. >>>> >>>> Some anticipated objections: >>>> >>>> 1. signaling isn't voting, no deployment should be made without >>>> consensus first. >>>> - yeah well we can't currently measure consensus right now, so that's >>>> not a super helpful thing to say and is breeding ground for abuse in the >>>> form of certain people making the unsubstantiated claim that consensus does >>>> or does not exist for a particular initiative >>>> >>>> 2. This is just a proposal for "pay to play", we should not let the >>>> wealthy make consensus decisions. >>>> - I agree that wealth should not be able to strong-arm decision making. >>>> But the status quo seems even worse where we let publicly influential >>>> people decide consensus in such a way where not only do they not "lose >>>> ammunition" in the process of campaigning, but actually accrue it, creating >>>> really bad long-term balances of power. >>>> >>>> 3. Enforcing this proposal requires its own soft fork. >>>> - Yes. It does...and there's a certain cosmic irony to that, but before >>>> we consider how to make this happen, I'd like to even discuss whether or >>>> not it's a good idea. >>>> >>>> 4. This gives CoinJoin pool operators and L2 protocol implementations >>>> power over deciding consensus. >>>> - I see this as an improvement over the status quo >>>> >>>> 5. This encourages "spam" >>>> - If you pay the fees, it's not spam. >>>> >>>> The biggest question I'd like to pose to the forum is: >>>> - Does a scheme like this afford us a better view into consensus than >>>> we have today? >>>> - Can it be gamed to give us a *worse* view into consensus? How? >>>> - Does it measure the right thing? If not, what do you think is the >>>> right thing to measure? (assuming we could) >>>> - Should I write a BIP spec'ing this out in detail? >>>> >>>> Cheers, >>>> Keagan >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> >>> >>> -- >>> - Bryan >>> https://twitter.com/kanzure >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
