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

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

[Keagan McClelland]

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

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

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

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

[Bryan Bishop]

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

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

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

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

[Billy Tetrud]

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

>   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
>

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

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

[Chris Riley]

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

>> 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
>

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

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

[Erik Aronesty]

[-- 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 --]

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

[Billy Tetrud]

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

@Erik
>  Miners can block votes from the chain

This would seem to not realistically ever happen in Keagan's proposal,
since miners can only include transactions that signal the same way they're
signaling. So yes, they could block those transactions, but it would be
very much against their interests to do so, and they cannot block
transactions that signal against them. That is assuming that *some* miners
signal differently. If literally (or practically) 100% of the miners signal
the same way, then you're right that it blocks alternative signals, but at
the same time, the signals will still be there in the mempool for all to
see at the time.

The other points against this style of transaction signaling sound correct
to me.

>  We can collect votes off-chain by signing messages and publishing them
"somewhere", but where would that be?

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.

In that proposal, a central publishing place is not necessary, as any
comparison of two different sets of poll results can simply be merged into
one set to get the most accurate picture. It would be very easy to see if
someone is dishonestly publishing incomplete poll results. In a proper
implementation of this, everyone should be able to have poll results that
match almost exactly, especially when looking at the results for eg > 1
week in the past.

> How do you make this 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), and anyone who wants to
collect poll data simply collects it all. That would be censorship
resistant in the exact same way bitcoin is censorship resistant.

>  Suppose someone's coins are protected by a hot/cold covenant, like TLUV
or CTV: parse scripts?  Ick.

Ideally, address types would take this into account. In taproot, one could
simply sign a poll message with the key spendpath key but one could also
embed a poll-signing path in a particular unspendable leaf in the MAST if
they want to designate a different poll-signing key. For non-taproot, an
address format could be redefined to be, instead of hash(publickey), to be
hash(hash(publickey)+hash(pollSigningKey)). Or something similar. That way
the spending public key doesn't need to be revealed in order to sign a poll
message.

Similar structures could be added to any script configuration to allow
signing of polls without any significant exposure.

On Wed, Apr 27, 2022 at 9:28 AM Erik Aronesty <erik@q32.com> wrote:

> 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: 20738 bytes --]

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

[Erik Aronesty]

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

>
>
>
> 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: 2799 bytes --]

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

[Billy Tetrud]

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

  @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: 9789 bytes --]

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

[Billy Tetrud]

[-- 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 --]

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

[Billy Tetrud]

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

@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.
>>>
>>>

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

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

[ZmnSCPxj]

Good morning Billy,

> @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.

Note that "the goal of this thing" is part of the information where both "start from" here.

Even if you and I have different goals, if we both think about "given this goal, and these facts, is X the best solution available?" we will both agree, though our goals might not be the same as each other, or the same as "this goal" is in the sentence.
What is material is simply that the laws of logic are universal and if you include the goal itself as part of the question, you will reach the same conclusion --- but refuse to act on it (and even oppose it) because the goal is not your own goal.

E.g. "What is the best way to kill a person without getting caught?" will probably have us both come to the same broad conclusion, but I doubt either of us has a goal or sub-goal to kill a person.
That is: if you are perfectly rational, you can certainly imagine a "what if" where your goal is different from your current goal and figure out what you would do ***if*** that were your goal instead.

Is that better now?

> > 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 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.


Using a future market has the attractive property that, since money is often an instrumental sub-goal to achieve many of your REAL goals, you can get reasonably good information on the goals of people without them having to actually reveal their actual goals.
Also, irrationality on the market tends to be punished over time, and a human who achieves better-than-human rationality can gain quite a lot of funds on the market, thus automatically re-weighing their thoughts higher.

However, persistent irrationalities embedded in the design of the human mind will still be difficult to break (it is like a program attempting to escape a virtual machine).
And an uninformed market is still going to behave pretty much randomly.

Regards,
ZmnSCPxj

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

[Billy Tetrud]

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

>  if you are perfectly rational, you can certainly imagine a "what if"
where your goal is different from your current goal and figure out what you
would do ***if*** that were your goal instead.

I see what you're saying, and I'm a lot more on board with that. I still
think "rational" can't mean "perfect" - like "perfectly rational" is not
the same as "you magically get to the optimal answer". But I think my line
of thinking on this is a lot more pedantic than my previous contention. But
I will agree that for a given specific objective goal (that ignores other
goals), there is an objective set of answers that any logical person should
eventually be able to agree on. Of course, if there's any subjectivity in
the goal, then discussing the goal amongst two different people will really
mean that each of them are discussing slightly different goals, which
breaks the premise. So really for alignment to happen, the goal in question
needs to be really specific in order to remove any significant
subjectivity.

> better-than-human rationality

I like to think of rationality in the following way. Any economic actor is
a being that has goals they want to maximize for, and tools at their
disposal to analyze and affect their world. A rational actor is one that
attempts to use their tools to the best of their ability to maximize their
goals. Perhaps goals is a misleading word to use here, since it implies
something that can be achieved, whereas I really mean a set of weighted
metrics that can hypothetically always be improved upon. But in any case, a
human starts with goals built into their genetics, which in turn build
themselves into the structure of their body. The tools a human has is also
their body and their brain. The brain is not a perfect tool, and neither is
the rest of the body. However, humans use what they have to make decisions
and act on their world. The goals a human has evolve as they have
experiences in the world (which end up physically changing their brain). In
this sense, every human, and every possible actor really, must be a
rational actor. They're all doing the best they can, even if the tools at
their disposal are very suboptimal for maximizing their underlying goals.
What more can you ask of a rational actor than to use the tools they have
to achieve their goals?

So I don't think anyone is more or less "rational" than anyone else. They
just have different goals and different levels of ability to maximize those
goals. In my definition above, the goals are completely arbitrary. They
don't have to be anything in particular. A person could have the goal of
maximizing the number of paper clips in the world, at all other costs. This
would almost certainly be "bad" for that person, and "bad" for the world,
but if that's really what their goals are, then that "badness" is a
subjectivity that you and I would be placing on that goal because our goals
are completely different from it. To the being with that goal, it is a
totally perfect goal.

The idea that someone can be "more rational" than someone else kind of
boils everything down to one dimension. In reality, everyone has their
different skills and proficiencies. In a futures market, you might be
better at predicting the price of salmon, but you might be quite bad at
predicting human population changes over time. Does this mean you're "more
rational" about salmon but "less rational" about how human populations
change? I would say a better way to describe this is proficiency, rather
than rationality.

</digression>

> a future market

A futures market for predictions is an interesting idea. I haven't really
heard about such a thing really being done other than in little
experiments. Are you suggesting we use one to help make decisions about
bitcoin? One issue is that the questions a futures market answers have to,
like my conclusion in the above paragraph, be completely objective. So a
futures market can't answer the question "what's the best way to design
covenants?" tho it could answer the question "will CTV be activated by
2024?". But as a consequence, I don't think a future's market could help
much in the formulation of appropriate goals for bitcoin. That would need
to be hashed out by making a lot of different compromises amongst
everyone's various subjective opinion's about what is best.

And I think that's really what I'm suggesting here, is that we bitcoiners
discuss what the objective goals of bitcoin should be, or at least what
bounds on those goals there should be. And once we have these objective
goals, we can be aligned on how to appropriately solve them. It wouldn't
avoid the nashing of teeth needed to hash out the subjective parts of our
opinions in getting to those goals, but it could avoid much nashing of
teeth in the other half of the conversation: how to achieve the goals we
have reached consensus on.

Eg, should a goal of bitcoin be that 50% of the world's population should
require spending no more than 1% of their income to be able to run a full
node? Were we to decide on something akin to that, it would at least be a
question that has an objective truth value to it, even if we couldn't
feasibly confirm to 100% certainty whether we have achieved it, we could
probably confirm with some acceptable level of certainty below 100%.



On Sat, Apr 30, 2022 at 1:14 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Billy,
>
> > @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.
>
> Note that "the goal of this thing" is part of the information where both
> "start from" here.
>
> Even if you and I have different goals, if we both think about "given this
> goal, and these facts, is X the best solution available?" we will both
> agree, though our goals might not be the same as each other, or the same as
> "this goal" is in the sentence.
> What is material is simply that the laws of logic are universal and if you
> include the goal itself as part of the question, you will reach the same
> conclusion --- but refuse to act on it (and even oppose it) because the
> goal is not your own goal.
>
> E.g. "What is the best way to kill a person without getting caught?" will
> probably have us both come to the same broad conclusion, but I doubt either
> of us has a goal or sub-goal to kill a person.
> That is: if you are perfectly rational, you can certainly imagine a "what
> if" where your goal is different from your current goal and figure out what
> you would do ***if*** that were your goal instead.
>
> Is that better now?
>
> > > 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 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.
>
>
> Using a future market has the attractive property that, since money is
> often an instrumental sub-goal to achieve many of your REAL goals, you can
> get reasonably good information on the goals of people without them having
> to actually reveal their actual goals.
> Also, irrationality on the market tends to be punished over time, and a
> human who achieves better-than-human rationality can gain quite a lot of
> funds on the market, thus automatically re-weighing their thoughts higher.
>
> However, persistent irrationalities embedded in the design of the human
> mind will still be difficult to break (it is like a program attempting to
> escape a virtual machine).
> And an uninformed market is still going to behave pretty much randomly.
>
> Regards,
> ZmnSCPxj
>

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

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

[Ryan Grant]

We had a UTXO proof-of-stake website at some point during the
blocksize wars.  A few people signed with a few thousand bitcoins, but
it was clear that most were not participating.  I don't have a link.

Another old discussion link:
  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June/002731.html

Erik Aronesty listed good issues, a few minutes ago.

Other issues:
  - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
  - signalling should be weighted by Bitcoin Days Destroyed [ref_bdd];
  - Coinbase.com's interests are not sufficiently aligned to poll them; and
  - yuk, it's voting.

Without supporting voting, I wish to note there is also one more way
to de-Sybil, via network analysis, historically labeled the Web of
Trust.  It can be algorithmically blinded so as not to fit strongly
into your "KYC" category, despite using assertions about people that
do know each other as a ground truth.

[ref_bdd:]
  https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed

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

[micaroni]

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

The idea seems interesting at first glance, but soon we see several
problems. The biggest problem with votes of this type is that they can be
easily manipulated. Imagine a powerful attacker who impersonates someone in
good faith and arrives with a proposal that looks great but has dark ends
behind it (and that no one has simply noticed yet). It would be enough for
this attacker to convince major wallets, major exchanges and even
individuals to believe him. It could be with a good marketing campaign or
even buying these people. This would create a "false consensus", a
misconception of what consensus means.

For me, 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, because they
understand far better than any other lowly mortal. Consensus simply means
that there are not at least two or three important people opposing the idea
with solid arguments. Is it very subjective and difficult? Yes. For sure.
We all yearn for objective answers or methods. However, any method would
fail. At the end, after numerous discussions and an apparent consensus, the
objective answer and the real consensus will be obtained in the network, in
the nodes upgrading. If there is a big war, the network will end up
splitting in two, as it has in the past. To avoid any unwanted splits we
discuss for exhaustion here in the list.

I don't think flagging transactions would be a good method to measure this
sort of thing. You are handing important technical discussions into the
hands of those who have no idea about the subject.

Felipe.

On Tue, Apr 26, 2022 at 5: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
>

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

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

[Keagan McClelland]

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

Felipe,

> For me, 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, because they
understand far better than any other lowly mortal. Consensus simply means
that there are not at least two or three important people opposing the idea
with solid arguments. Is it very subjective and difficult? Yes. For sure.
We all yearn for objective answers or methods. However, any method would
fail. At the end, after numerous discussions and an apparent consensus, the
objective answer and the real consensus will be obtained in the network, in
the nodes upgrading. If there is a big war, the network will end up
splitting in two, as it has in the past. To avoid any unwanted splits we
discuss for exhaustion here in the list.

This is essentially an admission that devs have control over the protocol.
Users "having control" but deferring their judgement to devs is not
meaningfully different than devs "having control". Many people have
asserted, quite strongly, that this ought not be how Bitcoin governs
itself. I myself am on the fence about what is practically possible or not.
However, let's say that your supposition is correct. How would we protect
against a corollary scenario where a dev has a proposal that looks great
but has dark ends that no one notices yet, if the process for evaluation
more or less is to defer to "the most important devs" expertise? Presumably
we hash this out in forums like this, but in order to "override" the "most
important devs" we have to have a way (formalized or not) of deciding when
the "lesser experts" in aggregate have better judgement.

Erik,

> There are many challenges with on-chain voting, here are a few:

This may be hair-splitting but I feel it important to clarify that my
proposal isn't voting per se. Calling it that doesn't bug me, but the
mechanics are meaningfully different than a simple tally vote which is the
intuition that I think that term conveys. As Billy mentions this proposal
actually requires that miners block signals from inclusion in the block if
they themselves do not signal. I'm not necessarily claiming this is a
superior design overall, however the "flaw" you point out is by design in
this case. My goal in the proposal was really to give users a means of
applying direct economic pressure to miners, who do inevitably play a role
in BIP8/BIP9 activation procedure.

Ryan,

> - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;

Definitely a frightening proposition I hadn't considered. It does open up
the possibility of tracking individual preferences and targeting of
political opponents.

>   - yuk, it's voting.

I don't think the process of collecting information on user preference is
in and of itself bad. Where I think Bitcoiners really want to avoid voting
is this notion that 51% of the constituency can bully the other 49% into
whatever they want. No part of my proposal suggests this, nor is it
something I would want.

-----

I think there are a few questions surrounding the issue of soft fork
activation. Perhaps it warrants zooming out beyond even what my proposal
aims to solve. In my mind the most important questions surrounding this
process are:

1. In an ideal world, assuming we could, with perfect certainty, know
anything we wanted about the preferences of the user base, what would be
the threshold for saying "this consensus change is ready for activation"?
    1a. Does that threshold change based on the nature of the consensus
change (new script type/opcode vs. block size reduction vs. blacklisting
UTXOs)?
    1b. Do different constituencies (end users, wallets, exchanges,
coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
maximum representation in this "threshold"?
2. Given an answer from #1, 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?
3. Can any of the answers to #2 be "gamed"? I'm defining "game" here to
mean that the measurement taken, diverges from the ground truth we are
trying to get at in such a way that its divergence would be undetectable.

If we do not answer these sorts of questions we can get technical consensus
through this messy process, but when it comes to assessing user consensus,
it is just going to devolve into dogma and demagoguery as we each have our
own perceptions or agendas and there is no rigorous way for anyone to
refute our claims. This would, again, be an admission that devs ultimately
do make protocol decisions. Perhaps it's unavoidable and we are doomed to
this painful process of arguing with one another until there's only one
opinion left standing (either because of merit or just plain old grit).
However, if this is the case, I don't think we can honestly claim that devs
don't control the protocol (as a group).

I don't think we will have broad agreement on #1 as it is ultimately a
value judgement and even the most intellectually honest people in Bitcoin
dev are going to have different value sets. I think this is OK, to a
degree. But where a lot of communication breakdown occurs is when people
are debating the properties of #2/#3 when they don't even know that there
is disagreement between them on #1. I think that everyone having an
individual answer to #1 can make these discussions go a lot more smoothly
in the technical sphere since I think most people can suspend their own
values for the sake of analyzing the effectiveness of a particular
approach. I am concerned, however, that if value differences are allowed to
be passed off as technical evaluations, the quality of the conversation may
erode to the point where no meaningful advancement can happen anymore,
since we will lose our shared framework for understanding. If this occurs
too soon, I believe quite strongly that Bitcoin will be captured through
the increasing power of custodial institutions.

Keagan

On Wed, Apr 27, 2022 at 11:22 AM <micaroni@gmail.com> wrote:

> The idea seems interesting at first glance, but soon we see several
> problems. The biggest problem with votes of this type is that they can be
> easily manipulated. Imagine a powerful attacker who impersonates someone in
> good faith and arrives with a proposal that looks great but has dark ends
> behind it (and that no one has simply noticed yet). It would be enough for
> this attacker to convince major wallets, major exchanges and even
> individuals to believe him. It could be with a good marketing campaign or
> even buying these people. This would create a "false consensus", a
> misconception of what consensus means.
>
> For me, 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, because they
> understand far better than any other lowly mortal. Consensus simply means
> that there are not at least two or three important people opposing the idea
> with solid arguments. Is it very subjective and difficult? Yes. For sure.
> We all yearn for objective answers or methods. However, any method would
> fail. At the end, after numerous discussions and an apparent consensus, the
> objective answer and the real consensus will be obtained in the network, in
> the nodes upgrading. If there is a big war, the network will end up
> splitting in two, as it has in the past. To avoid any unwanted splits we
> discuss for exhaustion here in the list.
>
> I don't think flagging transactions would be a good method to measure this
> sort of thing. You are handing important technical discussions into the
> hands of those who have no idea about the subject.
>
> Felipe.
>
> On Tue, Apr 26, 2022 at 5: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
>>
>

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

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

[ZmnSCPxj]

Good morning Keagan, et al,



> I think there are a few questions surrounding the issue of soft fork activation. Perhaps it warrants zooming out beyond even what my proposal aims to solve. In my mind the most important questions surrounding this process are:
>
> 1. In an ideal world, assuming we could, with perfect certainty, know anything we wanted about the preferences of the user base, what would be the threshold for saying "this consensus change is ready for activation"?
>     1a. Does that threshold change based on the nature of the consensus change (new script type/opcode vs. block size reduction vs. blacklisting UTXOs)?
>     1b. Do different constituencies (end users, wallets, exchanges, coinjoin coordinators, layer2 protocols, miners) have a desired minimum or maximum representation in this "threshold"?

Ideally, in a consensus system, 100% should be the threshold.
After all, the intent of the design of Bitcoin is that everyone should be able to use it, and the objection of even 0.01%, who would actively refuse a change, implies that set would not be able to use Bitcoin.
i.e. "consensus means 'everyone agrees'"

Against this position, the real world smashes our ideals.
Zooming out, the number of Bitcoin users in the globe is far less than 100%, and there are people who would object to the use of Bitcoin entirely.
This implies that the position "consensus means 'everyone agrees'" would imply that Bitcoin should be shut down, as it cannot help users who oppose it.
Obviously, the continued use of Bitcoin, by us and others, is not in perfect agreement with this position.

Let us reconsider the result of the blocksize debate.
A group of former-Bitcoin-users forked themselves off the Bitcoin blockchain.
But in effect: the opposers to SegWit were simply outright *evicted* from the set of people who are in 'everyone', in the "consensus means 'everyone agrees'" sense.
(That some of them changed their mind later is immaterial --- their acceptance back into the Bitcoin community is conditional on them accepting the current Bitcoin rules.)

So obviously there is *some* threshold, that is not 100%, that we would deem gives us "acceptable losses".
So: what is the "acceptable loss"?

--

More philosphically: the [Aumann Agreement Theorem](https://en.wikipedia.org/wiki/Aumann%27s_agreement_theorem) can be bastardized to: "if two people are perfectly rational and start from the same information, they *will* agree".

If humans were perfectly rational and the information was complete and accurately available beforehand, we could abduct a single convenient human being, feed them the information, and ask them what they think, and simply follow that.
It would be pointless to abduct a second human, since it would just agree with the first (as per the Aumann Agreement Theorem), and abducting humans is not easy or cheap.

If humans were perfectly rational and all information was complete, then there would be no need for "representation", you just input "this is my goal" and "this is the info" and get out "aye" or "nay", and whoever you gave those inputs to would not matter, because everyone would agree on the same conclusion.

All democracy/voting and consensus, stem from the real-world flaws of this simple theorem.

1.  No human is perfectly rational in the sense required by the Aumann Agreement Theorem.
2.  Information may be ambiguous or lacking.
3.  Humans do not want to reveal their *actual* goals and sub-goals, because their competitors may be able to block them if the competitors knew what their goals/sub-goals were.

Democracy, and the use of some kind of high "threshold" in a "consensus" (ha, ha) system, depend on the following assumptions to "fix" the flaws of the Aumann Agreement Theorem:

1.  With a large sample of humans, the flaws in rationality (hopefully, ha, ha) cancel out, and if we ask them *Really Nicely* they may make an effort to be a little nearer to the ideal perfect rationality.
2.  With a large sample of humans, the incompleteness and obscureness of the necessary information may now become available in aggregate (hopefully, ha, ha), which it might not be individually.
3.  With a large sample of humans, hopefully those with similar goals get to aggregate their goals, and thus we can get the most good (achieved goals) for the greatest number.

Unfortunately, democracy itself (and therefore, any "consensus" ha ha system that uses a high threshold, which is just a more restricted kind of democracy that overfavors the status quo) has these flaws in the above assumptions:

1.  Humans belong to a single species with pretty much a single brain design ("foolish humans!"), thus flaws in their rationality tend to correlate, so aggregation will *increase* the error, not decrease it.
2.  Humans have limited brain space ("puny humans!") which they often assign to more important things, like whether Johnny Depp is the victim or not, and thus the information needed to make a good decision on inconsequential things, like Bitcoin (the future of money and hopefully a key to more prosperity for our civilization), may still not be available.
3.  Human goals and sub-goals may be so disparate and incompatible that the result is instead an unfocused, scattered mess.

In conclusion, what we need to do is to eliminate these humans and hand over control of the world to an AI from outside of space and time.

Unfortunately, we do not have access to such an AI, and instead must make do with mere humans.


But in principle, *everything* other than "just ask some random human and do what they think is good" are simply attempts to work around the known issues of real-world application of the Aumann Agreement Theorem.
Instead of increasingly-complicated solutions, could we attack the issues directly so we can settle for the simplest (but known flawed due to the issues with direct application of the Aumann Agreement Theorem) solution?

1.  Can we improve the thinking of typical humans discussing this topic?
2.  Can we gather all the relevant information?
    - This seems easiest to tackle.
3.  Can we actually have the goals of all humans discussing this topic all laid out, *accurately*?
    - This may be impossible, given that human brains are not introspective enough to understand their own sub-conscious goals.


Of note is that the reason why "democracy works" (and also that "consensus ha ha works", given that we have already done eviction of some set of users before in order to maintain "consensus") is that widespread agreement on some topic, among more-rational-than-irrational humans, is evidence that a *purely rational* computational entity would decide the same thing.
That is, we assume that the minority whose view is rejected is either irrational, uninformed, or malicious (i.e. has goals incompatible with the rest) and therefore that if we evict them, the remainder achieves Aumann Agreement and the majority view is in fact, rational, well-informed, and goal-maximizing.



Regards,
ZmnSCPxj

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

[micaroni]

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

Hi Keagan,

The worst case scenario is: no new proposals are accepted and the Bitcoin
remains the same. This is not so bad. I think a bad actor will usually want
to *add* (or remove) something that breaks. I don't know if the boycott of
new proposals is as effective in breaking Bitcoin. It means the more
important devs are not in full control, but they have the (kind of) power
of veto if they have really rational arguments. The most harm they can do
is delay things a little.

But remember: after all, everyone is free to fork the code, try to change
something and perhaps create undesirable splits in the network.


Felipe.


On Wed, Apr 27, 2022 at 3:32 PM Keagan McClelland <
keagan.mcclelland@gmail.com> wrote:

> Felipe,
>
> > For me, 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, because they
> understand far better than any other lowly mortal. Consensus simply means
> that there are not at least two or three important people opposing the idea
> with solid arguments. Is it very subjective and difficult? Yes. For sure.
> We all yearn for objective answers or methods. However, any method would
> fail. At the end, after numerous discussions and an apparent consensus, the
> objective answer and the real consensus will be obtained in the network, in
> the nodes upgrading. If there is a big war, the network will end up
> splitting in two, as it has in the past. To avoid any unwanted splits we
> discuss for exhaustion here in the list.
>
> This is essentially an admission that devs have control over the protocol.
> Users "having control" but deferring their judgement to devs is not
> meaningfully different than devs "having control". Many people have
> asserted, quite strongly, that this ought not be how Bitcoin governs
> itself. I myself am on the fence about what is practically possible or not.
> However, let's say that your supposition is correct. How would we protect
> against a corollary scenario where a dev has a proposal that looks great
> but has dark ends that no one notices yet, if the process for evaluation
> more or less is to defer to "the most important devs" expertise? Presumably
> we hash this out in forums like this, but in order to "override" the "most
> important devs" we have to have a way (formalized or not) of deciding when
> the "lesser experts" in aggregate have better judgement.
>
> Erik,
>
> > There are many challenges with on-chain voting, here are a few:
>
> This may be hair-splitting but I feel it important to clarify that my
> proposal isn't voting per se. Calling it that doesn't bug me, but the
> mechanics are meaningfully different than a simple tally vote which is the
> intuition that I think that term conveys. As Billy mentions this proposal
> actually requires that miners block signals from inclusion in the block if
> they themselves do not signal. I'm not necessarily claiming this is a
> superior design overall, however the "flaw" you point out is by design in
> this case. My goal in the proposal was really to give users a means of
> applying direct economic pressure to miners, who do inevitably play a role
> in BIP8/BIP9 activation procedure.
>
> Ryan,
>
> > - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
>
> Definitely a frightening proposition I hadn't considered. It does open up
> the possibility of tracking individual preferences and targeting of
> political opponents.
>
> >   - yuk, it's voting.
>
> I don't think the process of collecting information on user preference is
> in and of itself bad. Where I think Bitcoiners really want to avoid voting
> is this notion that 51% of the constituency can bully the other 49% into
> whatever they want. No part of my proposal suggests this, nor is it
> something I would want.
>
> -----
>
> I think there are a few questions surrounding the issue of soft fork
> activation. Perhaps it warrants zooming out beyond even what my proposal
> aims to solve. In my mind the most important questions surrounding this
> process are:
>
> 1. In an ideal world, assuming we could, with perfect certainty, know
> anything we wanted about the preferences of the user base, what would be
> the threshold for saying "this consensus change is ready for activation"?
>     1a. Does that threshold change based on the nature of the consensus
> change (new script type/opcode vs. block size reduction vs. blacklisting
> UTXOs)?
>     1b. Do different constituencies (end users, wallets, exchanges,
> coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
> maximum representation in this "threshold"?
> 2. Given an answer from #1, 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?
> 3. Can any of the answers to #2 be "gamed"? I'm defining "game" here to
> mean that the measurement taken, diverges from the ground truth we are
> trying to get at in such a way that its divergence would be undetectable.
>
> If we do not answer these sorts of questions we can get technical
> consensus through this messy process, but when it comes to assessing user
> consensus, it is just going to devolve into dogma and demagoguery as we
> each have our own perceptions or agendas and there is no rigorous way for
> anyone to refute our claims. This would, again, be an admission that devs
> ultimately do make protocol decisions. Perhaps it's unavoidable and we are
> doomed to this painful process of arguing with one another until
> there's only one opinion left standing (either because of merit or just
> plain old grit). However, if this is the case, I don't think we can
> honestly claim that devs don't control the protocol (as a group).
>
> I don't think we will have broad agreement on #1 as it is ultimately a
> value judgement and even the most intellectually honest people in Bitcoin
> dev are going to have different value sets. I think this is OK, to a
> degree. But where a lot of communication breakdown occurs is when people
> are debating the properties of #2/#3 when they don't even know that there
> is disagreement between them on #1. I think that everyone having an
> individual answer to #1 can make these discussions go a lot more smoothly
> in the technical sphere since I think most people can suspend their own
> values for the sake of analyzing the effectiveness of a particular
> approach. I am concerned, however, that if value differences are allowed to
> be passed off as technical evaluations, the quality of the conversation may
> erode to the point where no meaningful advancement can happen anymore,
> since we will lose our shared framework for understanding. If this occurs
> too soon, I believe quite strongly that Bitcoin will be captured through
> the increasing power of custodial institutions.
>
> Keagan
>
> On Wed, Apr 27, 2022 at 11:22 AM <micaroni@gmail.com> wrote:
>
>> The idea seems interesting at first glance, but soon we see several
>> problems. The biggest problem with votes of this type is that they can be
>> easily manipulated. Imagine a powerful attacker who impersonates someone in
>> good faith and arrives with a proposal that looks great but has dark ends
>> behind it (and that no one has simply noticed yet). It would be enough for
>> this attacker to convince major wallets, major exchanges and even
>> individuals to believe him. It could be with a good marketing campaign or
>> even buying these people. This would create a "false consensus", a
>> misconception of what consensus means.
>>
>> For me, 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, because they
>> understand far better than any other lowly mortal. Consensus simply means
>> that there are not at least two or three important people opposing the idea
>> with solid arguments. Is it very subjective and difficult? Yes. For sure.
>> We all yearn for objective answers or methods. However, any method would
>> fail. At the end, after numerous discussions and an apparent consensus, the
>> objective answer and the real consensus will be obtained in the network, in
>> the nodes upgrading. If there is a big war, the network will end up
>> splitting in two, as it has in the past. To avoid any unwanted splits we
>> discuss for exhaustion here in the list.
>>
>> I don't think flagging transactions would be a good method to measure
>> this sort of thing. You are handing important technical discussions into
>> the hands of those who have no idea about the subject.
>>
>> Felipe.
>>
>> On Tue, Apr 26, 2022 at 5: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
>>>
>>

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

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

[Jeremy Rubin]

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

Generally speaking, I'm not too fond of these mechanisms, for reasons
others have expounded upon, but I will point out the following:

Taproot means that top-level keys can be used in a ring signature scheme to
collect coin votes from, e.g., all individual coins above a certain value
at a certain time without revealing the particulars of who signed.

This capability helps with some of the chainalysis concerns.

However, note that many thoughtful individuals do not currently have any
taproot outputs on mainchain AFAIK because wallets are not yet 'upgraded',
so it's more of a future possibility.

One thing that might be nice is if there were a way to sign with a NUMS
point for ring signature purposes, but not for transactions. Otherwise if
NUMS points are common these ring signatures protocols might not be too
useful for collecting signals (even if they remain useful for covering a
set including the NUMS pointed tr outs).

--
@JeremyRubin <https://twitter.com/JeremyRubin>

On Tue, Apr 26, 2022 at 1: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
>

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

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

[Nadav Ivgi]

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

Back in the 2017 block size wars I brought up the idea [0] of using
time-locked-weighted voting as a mechanism to gauge community/hodler
sentiment (lived on testnet for awhile at https://hodl.voting [1]).

Basically, the user locks up some bitcoins with an OP_CSV while committing
to some statement (using a pay-to-contract-hash construct in my
implementation[2]). Votes are then weighted as <lock duration> x <locked
btc amount>.

This has some interesting advantages over the more naive coin weighting
scheme used at the time (Bitcoinocracy [3]):

1. There's a real cost attached to voting, in the form of lost liquidity
and losing the ability to sell. The handicap principle suggests that this
makes for more reliable signaling, getting people to put more thought and
consideration into their vote (and whether they really care/know enough
about the issue to vote on it at all).
2. It shows that the voter has a long-term interest in the value of bitcoin
(and stands to lose if bitcoin is harmed), and gives more influence to
long-term hodlers that possess strong confidence in bitcoin.
3. Custodians don't get disproportionate voting power with their customers'
funds (not without getting themselves into fractional reserve, at least).
5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

A drawback is that in a chain-split scenario, you cannot use these bitcoins
to influence the markets (participate in futures markets, sell the side of
the split you want to see die off etc). But some people might not agree to
lose self-custody over their coins in order to do that, while with
time-weighted voting they can retain full self-custody. Or maybe they're
only willing to risk some X% on centralized futures markets, and still have
aside some Y% to allocate for timelocking.

To clarify, I don't really see this as 'voting' despite calling it that.
I'm definitely not advocating to use this as some authoritative
decision-making voting mechanism or as part of an activation mechanism,
only possibly as one more market signal to look at among many.

As for the proposal in the OP, it could be argued that mining fees are not
a highly reliable signal because users have to pay them anyway when
transacting, which makes the voting itself zero-cost (perhaps except for
waiting some more time to get it confirmed?). And as others have mentioned,
this gives influence primarily to transactors (the tx volume by exchanges
and payment processors easily eclipses that of end users) and not to
hodlers (while my idea does the exact opposite, so maybe makes sense to use
both?).

shesek

[0]
https://bitcoinmagazine.com/markets/hodlvoting-voting-your-bitcoins-better
[1] http://web.archive.org/web/20170710161455/https://hodl.voting/
[2] https://github.com/shesek/proof-of-hodl (hackathon grade code)
[3] Seems like a version of it now lives at
https://bitcoinocracy.herokuapp.com/

On Tue, Apr 26, 2022 at 11: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
>

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