summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorErik Aronesty <erik@q32.com>2022-04-27 10:28:31 -0400
committerbitcoindev <bitcoindev@gnusha.org>2022-04-27 14:28:48 +0000
commit80a4371333c0ee9b4575f24a6eb0d6e55a5277af (patch)
treeeeafc3dba8e26b06c92f7cf558001121e997cb4a
parentc4e507fbbcb8f6a66c8a357959aa0822e36c84b8 (diff)
downloadpi-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/bb831d133937e2af5280fa7a62cc5f6b7d86db628
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&#39;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 &quot;some=
+where&quot;, but where would that be?<br><div>- How do you make this censor=
+ship-resistant?<br>- Suppose someone&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
+xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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=
+>&gt;&gt; we should not let the wealthy make consensus decisions.</div><div=
+><br></div><div>&gt;We shouldn&#39;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>&gt;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>&gt;are disproportionately represented in the econ=
+omic majority. Attempting to subvert the economic majority seems like a bad=
+ idea.=C2=A0</div><div>&gt;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 &quot;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&#39;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 &lt;<a href=3D"mailto:bitcoi=
+n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
+oundation.org</a>&gt; 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">&gt;=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&#39;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&#39;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&#39;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&#39;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>&gt; we should not let the we=
+althy make consensus decisions.</div><div><br></div><div>We shouldn&#39;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>&gt; 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>&gt;=C2=A0Can it be gamed to give us =
+a *worse* view into consensus? How?</div><div>&gt; 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&#39;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 &lt;<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 &lt;<a href=3D"mailt=
+o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
+s.linuxfoundation.org</a>&gt; 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&#39;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&#39;t, what BIP8 T/F is or isn&#39;t etc. A s=
+ignificant reason for the breakdown in civility around this debate is that =
+because we don&#39;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 &quot;I w=
+ould support activation of ____ if there was consensus on it, but there isn=
+&#39;t&quot;. 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 &quot;it&#39;s obvious&quot;=
+, but the reality is that it fundamentally isn&#39;t. My bubble has a diffe=
+rent &quot;obvious&quot; 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&#39;t. As such &quot;miner signaling&quot; is cons=
+istently devalued as a signal for market demand. I don&#39;t think this is =
+reasonable since following the events of &#39;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&#39;ve had this idea floating aroun=
+d in the back of my head for a while, and I&#39;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&#39;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 &quot;free&quot; 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&#39;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&#39;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 &quot;real&quot; 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&#39;m proposing is =
+measurable completely en-protocol and doesn&#39;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 &gt;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&#39;t voting, no deployment should be made without consensus first.</=
+div><div>- yeah well we can&#39;t currently measure consensus right now, so=
+ that&#39;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 &quot;pay to play&quot;, 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 &quot;lose ammunition&quot; 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&#39;s a certain=
+ cosmic irony to that, but before we consider how to make this happen, I&#3=
+9;d like to even discuss whether or not it&#39;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 &quot;s=
+pam&quot;</div><div>- If you pay the fees, it&#39;s not spam.</div><div><br=
+></div><div>The biggest question I&#39;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&#39;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--
+