Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A9B7C002D for ; Wed, 27 Apr 2022 16:18:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 4E6F34053C for ; Wed, 27 Apr 2022 16:18:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3z2iMEMg_0m for ; Wed, 27 Apr 2022 16:18:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by smtp2.osuosl.org (Postfix) with ESMTPS id A1DB3403FF for ; Wed, 27 Apr 2022 16:18:09 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id i27so4405320ejd.9 for ; Wed, 27 Apr 2022 09:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1JXIKLVSmvnoKCWEbW+HnoPaLr7ETw1JzI+JI9aUm1o=; b=IZ0PrIE5QkpraK55hffGTNwFccjjrPTsMzvIsTbHew3EQGHxmnhj+o5B4ELWgOoJlN gOVzdFKmB1GJgsxlAk2Nt/UitKrERqELvKesVU3jXwYuvmelZiV1t7sW/jFPsclxmaUA 2ZqNIHROM1Q2+6Ck3pGx719T0mZzVPPYb1mOdtI0DX1KuTskux4YAmQ1/TsJeQph9Lim B+aoR006M4X9IZOyh/hlYdrnnuC1fGZ9K3qFqH2J5Y0u9nng3LNMf82zM1O4IoY/b15x 6lB8YRrCZsJX6wTmQfS0893WrFGMbQ6GD1hr5e4GzJAFJg+78KWHoCxEhhek6dmj1Qml lLNg== 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=1JXIKLVSmvnoKCWEbW+HnoPaLr7ETw1JzI+JI9aUm1o=; b=CFdJiZaqMF9vg8IiwyRkox8yN38YKfoyPDYwbPB11zs/7U7EYb2ly2lRT38HdgO/De Su/4SCubUCkjEe0SdBvxuloLCpYPke/j/dxInrRAYDrfSpY/QM5gLWFNDp50FCCocCcF lGB3UEpgU4qid8tumlz5QqBw7IEMWGimows7urjRZwL90+4HSrTpQ4GKD/SWuekIRNMo I4B/1DXaTIqBnsqDv+xLO//JDBPvUHDTbTLPltqHcIVAE0ZWw0rTuv6WVoO4gRsnrTSQ 83WG4apkucf13zbTi3Vn7Vcq3bX/0eUhSKhCo0395e0azgg7OF5HkVRtNcedD5i2RfyK yPnQ== X-Gm-Message-State: AOAM532r60NF68rJR3MGZTI3O+H6LMCWVk/0QYfRbcOV4aLLw8WvnpNx 6Mtrz+baIZczcAdqRet2kX+OrUmQqRhjTzUL0DOsT77FQMo= X-Google-Smtp-Source: ABdhPJxOfRMlc3/DhH8wmI1DDfWqUEx0Og2lycrWS8YPVwWoe+YiUstC1VTkH74xwKtJZlWPEGM631BT64vMOPlT2+A= X-Received: by 2002:a17:906:4fd5:b0:6f3:d23f:9ac6 with SMTP id i21-20020a1709064fd500b006f3d23f9ac6mr1950729ejw.281.1651076287504; Wed, 27 Apr 2022 09:18:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Wed, 27 Apr 2022 11:17:51 -0500 Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary="0000000000009d247c05dda5273b" X-Mailman-Approved-At: Wed, 27 Apr 2022 16:41:43 +0000 Cc: Bitcoin Protocol Discussion 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 16:18:12 -0000 --0000000000009d247c05dda5273b Content-Type: text/plain; charset="UTF-8" @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 ? 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 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 >> > --0000000000009d247c05dda5273b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Erik
>=C2=A0 Miners can block votes from the chain

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

The other points against this style of transaction sign= aling sound correct to me.

>=C2=A0 We can colle= ct votes off-chain by signing messages and publishing them "somewhere&= quot;, but where would that be?

Have you taken a l= ook at my proposal? The proposal is, to be clear, *not*= "voting" but rather polling that isn't programmatically conn= ected to activation. The intention is for people (developers) to look at th= e polling results and make an educated analysis of it as far as how it shou= ld contribute to consensus gathering.=C2=A0

In tha= t 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 d= ishonestly publishing incomplete poll results. In a proper implementation o= f this, everyone should be able to have poll results that match almost exac= tly, especially when looking at the results for eg > 1 week in the past.= =C2=A0

> How do you make this censorship-resist= ant?

Let's say everyone who participates in po= lling broadcasts it along the bitcoin network (a separate network would pro= bably 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 wo= uld be censorship resistant in the exact same way bitcoin is censorship res= istant.=C2=A0

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

Ideally, address types would take this= into account. In taproot, one could simply sign a poll message with the ke= y spendpath key but one could also embed a poll-signing path in a particula= r unspendable leaf in the MAST if they want to designate a different poll-s= igning key. For non-taproot, an address format could be redefined to be, in= stead 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.=C2=A0

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

On Wed, Apr 27, 2022= at 9:28 AM Erik Aronesty <erik@q32.com<= /a>> wrote:
<= div dir=3D"ltr">There are many challenges with on-chain voting, here are a = few:

- We may not want votes on-chain, because it creates miner inc= entives for contentious BIP's to drive up fees
- Miners c= an block votes from the chain
- Cold storage votes are probab= ly the most important for certain proposals (like vaulting), but are the le= ast-likely to vote
- Awareness and participation in blockchain vo= ting is typically very low and is mostly limited to big exchanges


On Wed, Apr 27, 2022 at 10:07 A= M Chris Riley via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
>> we should not let the wealthy make consensus dec= isions.

>We shouldn't let the wealthy conti= nue to control our governments. However, bitcoin is not a government. Its a= financial network.=C2=A0
>The fact of the matter is that = fundamentally, the economic majority controls where the chain goes. Its ver= y likely that the wealthy=C2=A0
>are disproportionately repres= ented in the economic majority. Attempting to subvert the economic majority= seems like a bad idea.=C2=A0
>The reality of control there wi= ll come out one way or another, and being honest about it is probably the b= est way to avoid major schisms in the future.=C2=A0

Yes, the economic majority=C2=A0is important: =C2=A0Who else has more inc= entive to protect the security and thus the value embodied in the network t= han people who have invested money and time in the network?=C2=A0 A group o= f people with 1/10/100/1000 bitcoins each has more economic incentive to do= so than a similar sized group with=C2=A01/10/100/1000=C2=A0satoshis each.= =C2=A0 Likewise, it is significantly=C2=A0easier to mobilize 1 million peop= le "voting" 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 peop= le, 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 vo= te was done whether via transaction flags or something else.=C2=A0 Of cours= e they could fork off.

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





On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.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
--0000000000009d247c05dda5273b--