path: root/84/bb831d133937e2af5280fa7a62cc5f6b7d86db

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