diff options
author | Erik Aronesty <erik@q32.com> | 2022-04-27 10:28:31 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-27 14:28:48 +0000 |
commit | 80a4371333c0ee9b4575f24a6eb0d6e55a5277af (patch) | |
tree | eeafc3dba8e26b06c92f7cf558001121e997cb4a | |
parent | c4e507fbbcb8f6a66c8a357959aa0822e36c84b8 (diff) | |
download | pi-bitcoindev-80a4371333c0ee9b4575f24a6eb0d6e55a5277af.tar.gz pi-bitcoindev-80a4371333c0ee9b4575f24a6eb0d6e55a5277af.zip |
Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks
-rw-r--r-- | 84/bb831d133937e2af5280fa7a62cc5f6b7d86db | 628 |
1 files changed, 628 insertions, 0 deletions
diff --git a/84/bb831d133937e2af5280fa7a62cc5f6b7d86db b/84/bb831d133937e2af5280fa7a62cc5f6b7d86db new file mode 100644 index 000000000..ce40a2b3e --- /dev/null +++ b/84/bb831d133937e2af5280fa7a62cc5f6b7d86db @@ -0,0 +1,628 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 301C0C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Apr 2022 14:28:45 +0000 (UTC) +Received: by mail-lj1-x231.google.com with SMTP id v4so2847897ljd.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com> + <CABaSBayKH__f_ahUUiDt2SiKik9aNLR1AXtG9RtWrFmTLP5qKw@mail.gmail.com> + <CAGpPWDbYj4+g4VPMT9FPqyUZWO+U98YQhgYan5fRqXjpd+dTyw@mail.gmail.com> + <CAL5BAw1pKXh4HLrUQByVMwpUtYyWcE5JhjUP-JB_1HKkORB1dA@mail.gmail.com> +In-Reply-To: <CAL5BAw1pKXh4HLrUQByVMwpUtYyWcE5JhjUP-JB_1HKkORB1dA@mail.gmail.com> +From: Erik Aronesty <erik@q32.com> +Date: Wed, 27 Apr 2022 10:28:31 -0400 +Message-ID: <CAJowKg+-qy00X_nSvFDz0HtvfjdsaozzGq4Vr8Vbd06GGZ8k_A@mail.gmail.com> +To: Chris Riley <criley@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000058945b05dda3a091" +X-Mailman-Approved-At: Wed, 27 Apr 2022 14:44:43 +0000 +Cc: Billy Tetrud <billy.tetrud@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + +<div dir=3D"ltr">There are many challenges with on-chain voting, here are a= + few:<div><br>- We may not want votes on-chain, because it creates miner in= +centives for contentious BIP's to drive up fees<br></div><div>- Miners = +can block votes from the chain<br></div><div>- Cold storage votes are proba= +bly the most important for certain proposals (like vaulting), but are the l= +east-likely to vote</div><div>- Awareness and participation in blockchain v= +oting is typically very low and is mostly limited to big exchanges</div><di= +v><br></div><div>And off chain voting is even worse:</div><div><br>- We can= + collect votes off-chain by signing messages and publishing them "some= +where", but where would that be?<br><div>- How do you make this censor= +ship-resistant?<br>- Suppose someone's coins are protected by a hot/col= +d covenant, like TLUV or CTV: parse scripts?=C2=A0 Ick.</div><div><br></div= +><div>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.</div><div><div></div></div></div></div><br><div class=3D"gmail_= +quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27, 2022 at 10:07 = +AM Chris Riley via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linu= +xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></= +div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= +der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div= +>>> we should not let the wealthy make consensus decisions.</div><div= +><br></div><div>>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<br></div><div>>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</div><div>>are disproportionately represented in the econ= +omic majority. Attempting to subvert the economic majority seems like a bad= + idea.=C2=A0</div><div>>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</div><div><br></div><div>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.</div><div><br></div><div>Cheers, =C2=A0 =C2=A0:-)</div><div>Chris</div= +><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div= + class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27= +, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <<a href=3D"mailto:bitcoi= +n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf= +oundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= +le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= +ng-left:1ex"><div dir=3D"ltr">>=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<div><br></div><div>I fe= +el like I've heard this idea somewhere before. Its an interesting idea.= +=C2=A0</div><div><br></div><div>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.</div><div><br></div><div>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.</di= +v><div><br></div><div>An alternative I proposed was a way to do weighted po= +lling of holders:=C2=A0</div><div><a href=3D"https://lists.linuxfoundation.= +org/pipermail/bitcoin-dev/2022-March/020146.html" target=3D"_blank">https:/= +/lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html</a>= +</div><div><br></div><div>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.</div><div><br></div><div>> we should not let the we= +althy make consensus decisions.</div><div><br></div><div>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</div><div><br></div><div>> Does a scheme like this afford=C2=A0u= +s a better view into consensus than we have today?</div><div><br></div><div= +>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.</div><div><br></div><div>>=C2=A0Can it be gamed to give us = +a *worse* view into consensus? How?</div><div>> Does it measure the righ= +t thing? If not, what do you think is the right thing to measure?<br></div>= +<div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class=3D"gmail_qu= +ote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 3:49 PM = +Bryan Bishop via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxf= +oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&= +gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= +px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = +dir=3D"ltr">You may be interested in these posts on transaction signalling:= +<br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017= +-April/014193.html" target=3D"_blank">https://lists.linuxfoundation.org/pip= +ermail/bitcoin-dev/2017-April/014193.html</a><br><a href=3D"https://lists.l= +inuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html" target=3D"= +_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/= +014202.html</a><br><a href=3D"https://lists.linuxfoundation.org/pipermail/b= +itcoin-dev/2017-May/014251.html" target=3D"_blank">https://lists.linuxfound= +ation.org/pipermail/bitcoin-dev/2017-May/014251.html</a><br><br></div><br><= +div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr= + 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <<a href=3D"mailt= +o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list= +s.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= +4);padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div= +>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.</div><div><br></div><div= +>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><div><br></div><div>So how can we measure User Support for a proposed = +rule change?</div><div><br></div><div>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.</div><div><br></d= +iv><div>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:<br><br>- A transaction signaling in the= + affirmative MUST NOT be included in a block that does not signal in the af= +firmative<br>- A transaction that is NOT signaling MAY be included in a blo= +ck regardless of that block's signaling vector</div><div>- (Optional) A= + transaction signaling in the negative MUST NOT be included in a block that= + signals in the affirmative</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></d= +iv><div>- Hashpower</div><div>- Proof of personhood (KYC)<br>- Capital burn= +/risk</div><div><br></div><div>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.</div><div><br></= +div><div>There are many potential tweaks to the design I propose above:</di= +v><div>1. Do we include a notion of negative signaling (allowing for the po= +ssibility of rejection)</div><div>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><div><br><= +/div><div>Some anticipated objections:</div><div><br></div><div>1. signalin= +g isn't voting, no deployment should be made without consensus first.</= +div><div>- 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</div><div><br></di= +v><div>2. This is just a proposal for "pay to play", we should no= +t let the wealthy make consensus decisions.</div><div>- 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.</div><div><br></div><div>3. Enforcing this proposal requi= +res its own soft fork.</div><div>- 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.</div><div><br= +></div><div>4. This gives CoinJoin pool operators and L2 protocol implement= +ations power over deciding consensus.</div><div>- I see this as an improvem= +ent over the status quo</div><div><br></div><div>5. This encourages "s= +pam"</div><div>- If you pay the fees, it's not spam.</div><div><br= +></div><div>The biggest question I'd like to pose to the=C2=A0forum is:= +</div><div>- Does a scheme like this afford=C2=A0us a better view into cons= +ensus than we have today?</div><div>- Can it be gamed to give us a *worse* = +view into consensus? How?</div><div>- Does it measure the right thing? If n= +ot, what do you think is the right thing to measure? (assuming we could)</d= +iv><div>- Should I write a BIP spec'ing this out in detail?</div><div><= +br></div><div>Cheers,</div><div>Keagan</div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= +><div dir=3D"ltr">- Bryan<br><a href=3D"https://twitter.com/kanzure" target= +=3D"_blank">https://twitter.com/kanzure</a></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000058945b05dda3a091-- + |