Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 301C0C002D for ; Wed, 27 Apr 2022 14:28:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1690A41A2B for ; Wed, 27 Apr 2022 14:28:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdOR_-ZpH2Xz for ; Wed, 27 Apr 2022 14:28:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7D4F841A0C for ; Wed, 27 Apr 2022 14:28:45 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id v4so2847897ljd.10 for ; Wed, 27 Apr 2022 07:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=32tOctJ9fq5Y5ybkpXQ22ToPn8e48drTxhhSecdPxvU=; b=JVWT6qiNLP+p9RylNxxJfB0bhq0YFISltSt2Y7K3jWdWaIhTuD9lE6cWbT7X6SSh+a gEqo5B5VuwKH+Gru6IPGrb73KwVU6mhfDxjf+uCzxILKdKByWlAUs4wJM/kY9j6hOSzr 41F+jixhBj2mxHKnsBQsx4d3YadMZmjKDryFg1fLgOlkJ23mu7JqoRtwskbQcW1fn7ZW m0bBMtm++gIgdVN9H+BnScVF32zxX1nXcU9V5nWqIXZ6NLp+lDbKnJCjn/zyA7QxjCzq YSHRBW0TVowpSAUTWDkLz+lo+ZaIOBps+5YmD7XLrkaAguYE4TQIqsZ3x2xQAjotZ4M3 uJHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=32tOctJ9fq5Y5ybkpXQ22ToPn8e48drTxhhSecdPxvU=; b=Ko7ZHxRVL+MAzAWG8SfNvGboGhnYL+F99TpXPvJB2mlZfkeHWCKNW05n53L2txzkqW HbFZlk82dkL0v27pWsT4j4OKr5OsK3MJ1D6ziM/WtZkpri27nPl0XNM51i2v3HsSNMtu S4+p2lLi6cevmlYYYx0s/6bParLTKiFxn14H3/MemIbNiBc9PkSx52AgGSJPc4ioZN6p wFpNiZ0Ew00W2WsJ70hiZz4mpwnNGZAH+90Zn6AvOZUpFENZKUjv7Yupah2QXnInmQ9F 2T50hNaU/wBc82qSNHCWHHCE4M1M8hnWWETAmIgU+kSqLqfqYwpp9WlCXtIhRD57nF+P aI4w== X-Gm-Message-State: AOAM5312kRXd0eaZjwf6pq4BwKOdHw/scx/w/MYdLuis+fXPA7dBDyUb 7Gmja+LZyvVrCOt6Kp9hN4yREocgBX377QUUY4KOCD8jlu/Q+QA= X-Google-Smtp-Source: ABdhPJyEYvxkmvCOTKm2BOU0c8/6TkJ8NYixNLymk32fXXETNCC9ftE30INKfBHV07PuAXQp1erMGJAbijEJNXJG+JA= X-Received: by 2002:a2e:9259:0:b0:24f:2a6b:bf55 with SMTP id v25-20020a2e9259000000b0024f2a6bbf55mr2258013ljg.64.1651069723119; Wed, 27 Apr 2022 07:28:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Wed, 27 Apr 2022 10:28:31 -0400 Message-ID: To: Chris Riley , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000058945b05dda3a091" X-Mailman-Approved-At: Wed, 27 Apr 2022 14:44:43 +0000 Cc: Billy Tetrud Subject: Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 14:28:48 -0000 --00000000000058945b05dda3a091 Content-Type: text/plain; charset="UTF-8" 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 > --00000000000058945b05dda3a091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are many challenges with on-chain voting, here are a= few:

- We may not want votes on-chain, because it creates miner in= centives for contentious BIP's to drive up fees
- Miners = can block votes from the chain
- Cold storage votes are proba= bly the most important for certain proposals (like vaulting), but are the l= east-likely to vote
- Awareness and participation in blockchain v= oting 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 "some= where", but where would that be?
- How do you make this censor= ship-resistant?
- Suppose someone's coins are protected by a hot/col= d covenant, like TLUV or CTV: parse scripts?=C2=A0 Ick.

Although I do wish sometimes that this were not the case, I feel like= the verbal wrangling and rough/messy-consensus building=C2=A0remains our b= est 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 ou= r governments. However, bitcoin is not a government. Its a financial networ= k.=C2=A0
>The fact of the matter is that fundamentally, th= e economic majority controls where the chain goes. Its very likely that the= wealthy=C2=A0
>are disproportionately represented in the econ= omic majority. Attempting to subvert the economic majority seems like a bad= idea.=C2=A0
>The reality of control there will come out one w= ay or another, and being honest about it is probably the best way to avoid = major schisms in the future.=C2=A0

Yes, the econom= ic majority=C2=A0is important: =C2=A0Who else has more incentive to protect= the security and thus the value embodied in the network than people who ha= ve invested money and time in the network?=C2=A0 A group of people with 1/1= 0/100/1000 bitcoins each has more economic incentive to do so than a simila= r sized group with=C2=A01/10/100/1000=C2=A0satoshis each.=C2=A0 Likewise, i= t is significantly=C2=A0easier to mobilize 1 million people "voting&qu= ot; with 100 satoshis each - a total of 1 BTC - =C2=A0vs 10000 people each = voting with 100 bitcoins each - a total of 1 million BTC.=C2=A0 I don't= think anyone would say that even if those 1 million people, for example, t= hought that we should increase the number of bitcoins via perpetual inflati= on it would be a good idea to listen to it however the vote was done whethe= r via transaction flags or something else.=C2=A0 Of course they could fork = off.

Cheers, =C2=A0 =C2=A0:-)
Chris





On Wed, Apr 27= , 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
>=C2=A0 =C2=A0A transaction signaling in the affirmative MUST NOT be included in a = block that does not signal in the affirmative=C2=A0

I fe= el like I've heard this idea somewhere before. Its an interesting idea.= =C2=A0

It should be noted that there is a conseque= nce of this: holders wouldn't have much say. People=C2=A0that 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 w= ho aren't transacting much. This would probably be a pretty good proxy = for future mining revenue that supports (or is against) a particular=C2=A0t= hing. 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=C2=A0thing= s that are good for transactors and bad for holders. Things like more coin = inflation, larger blocks, etc.

Another considerati= on 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 po= lling of holders:=C2=A0

The polling wouldn't be directly connected to= the activation mechanism in any way, but would just be a mechanism to gaug= e 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 th= at directly as well.

> we should not let the we= althy make consensus decisions.

We shouldn't l= et the wealthy continue to control our governments. However, bitcoin is not= a government. Its a financial network. The fact of the matter is that fund= amentally, the economic majority controls where the chain goes. Its very li= kely that the wealthy are disproportionately represented in the economic ma= jority. 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 ho= nest about it is probably the best way to avoid major schisms in the future= .=C2=A0

> Does a scheme like this afford=C2=A0u= s a better view into consensus than we have today?

It does more than provide a view. It directly changes the game theory arou= nd how activation works. If we wanted to simply get a better view into cons= ensus, we could allow the same thing, but allow any block to mine any trans= action regardless of transaction signaling. Then it would be more purely in= formational.

>=C2=A0Can it be gamed to give us = a *worse* view into consensus? How?
> Does it measure the righ= t thing? If not, what do you think is the right thing to measure?
=

Doesn't seem like it could be gamed, but as I menti= oned above, the honest mechanics of it might be themselves undesirably dist= orting.



On Tue, Apr 26, 2022 at 3:49 PM = Bryan Bishop via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:

<= div class=3D"gmail_quote">
On Tue, Apr= 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <bitcoin-dev@list= s.linuxfoundation.org> wrote:
Hi all,

Alongside = the debate with CTV right now there's a second debate that was not full= y hashed out in the activation of Taproot. There is a lot of argument aroun= d what Speedy Trial is or isn't, what BIP8 T/F is or isn't etc. A s= ignificant reason for the breakdown in civility around this debate is that = because we don't have a means of measuring user support for proposed so= f-fork changes, it invariably devolves into people claiming that their circ= les support/reject a proposal, AND that their circles are more broadly repr= esentative of the set of Bitcoin users as a whole.

It seems everyone in this forum has at one point or another said "I w= ould support activation of ____ if there was consensus on it, but there isn= 't". This statement, in order to be true, requires that there exis= t a set of conditions that would convince you that there is consensus. Peop= le have tried to dodge this question by saying "it's obvious"= , but the reality is that it fundamentally isn't. My bubble has a diffe= rent "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 rules= ets get activated or don't. As such "miner signaling" is cons= istently devalued as a signal for market demand. I don't think this is = reasonable since following the events of '17=C2=A0=C2=A0miners are awar= e that they have the strong incentive that they understand market demand. N= evertheless, 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.<= /div>

So how can we measure User Support for a proposed = rule change?

I've had this idea floating aroun= d in the back of my head for a while, and I'd like to solicit some feed= back here. Currently, all forms of activation that are under consideration = involve miner signaling in one form or another. What if we could make it su= ch that users could more directly pressure miners to act on their behalf? A= fter all, if miners are but the humble servants of user demands, this shoul= d 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 tr= ansactions themselves can signal for upgrade. I believe (though am not cert= ain) that there are "free" bits in the version field of a transac= tion 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 af= firmative
- A transaction that is NOT signaling MAY be included in a blo= ck 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 cond= itions, a user has the means of sybil-resistant influence over miner decisi= ons. If a miner cannot collect the fees for a transaction without signaling= , the user's fee becomes active=C2=A0economic pressure for the miner to= signal (or not, if we include some variant of the negative clause). In thi= s 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 t= ry to compare a method like this to Proof of Stake, but there are only 3 sy= bil 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 t= hat 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 institut= ions that fork futures would. Additionally it could be an auxiliary=C2=A0fe= ature of the soft fork deployment scheme chosen making it something you cou= ld 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 po= ssibility of rejection)
2. Do we make it such that miner signalin= g must be congruent with >X% of transactions, where congruence is that t= he signal must match any non-neutral signal of transaction.

<= /div>
Some anticipated objections:

1. signalin= g 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 abu= se in the form of certain people making the unsubstantiated claim that cons= ensus does or does not exist for a particular initiative

2. This is just a proposal for "pay to play", we should no= t 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 su= ch a way where not only do they not "lose ammunition" in the proc= ess of campaigning, but actually accrue it, creating really bad long-term b= alances of power.

3. Enforcing this proposal requi= res 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= 9;d like to even discuss whether or not it's a good idea.
4. This gives CoinJoin pool operators and L2 protocol implement= ations power over deciding consensus.
- I see this as an improvem= ent over the status quo

5. This encourages "s= pam"
- If you pay the fees, it's not spam.
The biggest question I'd like to pose to the=C2=A0forum is:=
- Does a scheme like this afford=C2=A0us a better view into cons= ensus than we have today?
- Can it be gamed to give us a *worse* = view into consensus? How?
- Does it measure the right thing? If n= ot, what do you think is the right thing to measure? (assuming we could)
- Should I write a BIP spec'ing this out in detail?
<= br>
Cheers,
Keagan
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000058945b05dda3a091--