Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

From: Erik Aronesty <erik@q32•com>
To: Chris Riley <criley@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Billy Tetrud <billy.tetrud@gmail•com>
Subject: Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks
Date: Wed, 27 Apr 2022 10:28:31 -0400	[thread overview]
Message-ID: <CAJowKg+-qy00X_nSvFDz0HtvfjdsaozzGq4Vr8Vbd06GGZ8k_A@mail.gmail.com> (raw)
In-Reply-To: <CAL5BAw1pKXh4HLrUQByVMwpUtYyWcE5JhjUP-JB_1HKkORB1dA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 13891 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 17177 bytes --]