path: root/5e/dde369a9eaa82372c231dd8876b47873c3e1ba

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EEA28C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 03:04:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id D78B282F4F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 03:04:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tpaaWxrta8L3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 03:04:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp1.osuosl.org (Postfix) with ESMTPS id BFEEF82E14
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 03:04:21 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id l7so765607ejn.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 20:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=6Vv2PPBJi2+H8VTWfrXP1XA9u7kjRWKX3S6HGhRdSsM=;
 b=DRhdJcS7xJ9pyaUVeZkFjS90vM3r0htcPvEg1fgrF9OGfwMU9NExMLSz3euLPuxNKM
 hppku9Esl0eoJPtUGLzPkcZ9gUON/d5vgKnNTFxUEho5sSIqcd/cMMC4aBQ4QWUZiwhu
 Az7Zy3QYCcxzoFpWF+gSzSZeBpgzbk1wh1VPabAsSavYKnIZmmRrLKrFooSwSV54pk6q
 szxSfaXmq8npmSz34wXzhOUoxXl9xixJyO53/10TQZuTd/NUFdl8sAfbIuImD5T+NL/3
 mVu1vy7qT2wIj1XPF1TV7pP4lWAz/tWzuFLp5qKE4uAAUFkeOli96+HqCduorWzAne5j
 Yc+Q==
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=6Vv2PPBJi2+H8VTWfrXP1XA9u7kjRWKX3S6HGhRdSsM=;
 b=pHlb3wiPjYElF5WoEUZ1EOO1jSyajGVhwQos6QFInft4T8eXehmB7uKKq6LxDGkp+5
 iril3hT4ZSpimQdAPfrjZ7ldkowkTGqbEkoqReNezM6YZzbnNvdkNPVJz4rQnONrON1y
 pYam2Efg7pIRl76WhALux5endNW/PPJuZezkLxNeYOisyGk10Qjj1ea7Bi/Izogn8K8l
 H+BqSTTltQb7xDYu60nS8xDgaYXBmgWy4uylb0SGiupOGLfFeTZF3idvTnICrz/NqW2k
 qBduhBgzeI/K49YCuPOtb4vH+YmTHkH+kF33aR3TSAw28NbegxM+tjePO9f5taFix9tD
 zHWw==
X-Gm-Message-State: AOAM532jfK+j+T/2oXc4ryVZJOgOqnnCz4yaLY2Wc9n0imKSdE/swto2
 DDPeGivXxX8D5VscBZXbD7vNFciZDEQvXOHSvuA=
X-Google-Smtp-Source: ABdhPJxjVidgqzXLgI/XF6iOMneBW+f4MZowqXpesTrze7h1wGa3AGHBLgK22Gxp1xU87qOSncqTnjPvGUyi97hXuRI=
X-Received: by 2002:a17:907:3d91:b0:6df:a01c:f7cd with SMTP id
 he17-20020a1709073d9100b006dfa01cf7cdmr24371323ejc.255.1651028659640; Tue, 26
 Apr 2022 20:04:19 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
 <CABaSBayKH__f_ahUUiDt2SiKik9aNLR1AXtG9RtWrFmTLP5qKw@mail.gmail.com>
In-Reply-To: <CABaSBayKH__f_ahUUiDt2SiKik9aNLR1AXtG9RtWrFmTLP5qKw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 26 Apr 2022 22:04:04 -0500
Message-ID: <CAGpPWDbYj4+g4VPMT9FPqyUZWO+U98YQhgYan5fRqXjpd+dTyw@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c59c9c05dd9a1050"
X-Mailman-Approved-At: Wed, 27 Apr 2022 08:09:15 +0000
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 03:04:24 -0000

--000000000000c59c9c05dd9a1050
Content-Type: text/plain; charset="UTF-8"

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

--000000000000c59c9c05dd9a1050
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-March/020146.html</a></div><div><br></d=
iv><div>The polling wouldn&#39;t be directly connected to the activation me=
chanism 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 wel=
l.</div><div><br></div><div>&gt; we should not let the wealthy make consens=
us decisions.</div><div><br></div><div>We shouldn&#39;t let the wealthy con=
tinue to control our governments. However, bitcoin is not a government. Its=
 a financial network. The fact of the matter is that fundamentally, the eco=
nomic majority controls where the chain goes. Its very likely that the weal=
thy are disproportionately represented in the economic majority. Attempting=
 to subvert the economic majority seems like a bad idea. The reality of con=
trol there will come out one way or another, and being honest about it is p=
robably 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=A0us a better view in=
to consensus than we have today?</div><div><br></div><div>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 al=
low the same thing, but allow any block to mine any transaction regardless =
of transaction signaling. Then it would be more purely informational.</div>=
<div><br></div><div>&gt;=C2=A0Can it be gamed to give us a *worse* view int=
o consensus? How?</div><div>&gt; Does it measure the right thing? If not, w=
hat do you think is the right thing to measure?<br></div><div><br></div><di=
v>Doesn&#39;t seem like it could be gamed, but as I mentioned above, the ho=
nest mechanics of it might be themselves undesirably distorting.</div><div>=
<br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(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.linuxfo=
undation.org/pipermail/bitcoin-dev/2017-April/014193.html" target=3D"_blank=
">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193=
.html</a><br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2017-April/014202.html" target=3D"_blank">https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2017-April/014202.html</a><br><a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html" tar=
get=3D"_blank">https://lists.linuxfoundation.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 McClel=
land via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr">Hi all,<div><br></div><div>Alongside the debate with CTV right now ther=
e&#39;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&#39;=
t, what BIP8 T/F is or isn&#39;t etc. A significant reason for the breakdow=
n in civility around this debate is that because we don&#39;t have a means =
of measuring user support for proposed sof-fork changes, it invariably devo=
lves into people claiming that their circles support/reject a proposal, AND=
 that their circles are more broadly representative of the set of Bitcoin u=
sers as a whole.</div><div><br></div><div>It seems everyone in this forum h=
as at one point or another said &quot;I would support activation of ____ if=
 there was consensus on it, but there isn&#39;t&quot;. This statement, in o=
rder to be true, requires that there exist a set of conditions that would c=
onvince you that there is consensus. People have tried to dodge this questi=
on by saying &quot;it&#39;s obvious&quot;, but the reality is that it funda=
mentally isn&#39;t. My bubble has a different &quot;obvious&quot; answer th=
an any of yours.</div><div><br></div><div>Secondly, due to the trauma of th=
e 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&#39;t. As=
 such &quot;miner signaling&quot; is consistently devalued as a signal for =
market demand. I don&#39;t think this is reasonable since following the eve=
nts of &#39;17=C2=A0=C2=A0miners are aware that they have the strong incent=
ive that they understand market demand. Nevertheless, as it stands right no=
w 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 ca=
n we measure User Support for a proposed rule change?</div><div><br></div><=
div>I&#39;ve had this idea floating around in the back of my head for a whi=
le, and I&#39;d like to solicit some feedback here. Currently, all forms of=
 activation that are under consideration involve miner signaling in one for=
m 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 hu=
mble servants of user demands, this should be in alignment with how people =
want Bitcoin to behave.</div><div><br></div><div>Currently, the only means =
users have of influencing miner decisions are A. rejection of blocks that d=
on&#39;t follow rules and B. paying fees for transaction inclusion. I sugge=
st we combine these in such a way that transactions themselves can signal f=
or upgrade. I believe (though am not certain) that there are &quot;free&quo=
t; bits in the version field of a transaction that are presently ignored. I=
f we could devise a mapping between some of those free bits, and the signal=
ing 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 affirmative<br>- A transaction that =
is NOT signaling MAY be included in a block regardless of that block&#39;s =
signaling vector</div><div>- (Optional) A transaction signaling in the nega=
tive MUST NOT be included in a block that signals in the affirmative</div><=
div><br></div><div>Under this set of conditions, a user has the means of sy=
bil-resistant influence over miner decisions. If a miner cannot collect the=
 fees for a transaction without signaling, the user&#39;s fee becomes activ=
e=C2=A0economic pressure for the miner to signal (or not, if we include som=
e 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=
.</div><div><br></div><div>Some may take issue with the idea that people ca=
n pay for the outcome they want and may try to compare a method like this t=
o Proof of Stake, but there are only 3 sybil resistant mechanisms I am awar=
e of, and any &quot;real&quot; view into what social consensus looks like M=
UST be sybil resistant:</div><div><br></div><div>- Hashpower</div><div>- Pr=
oof of personhood (KYC)<br>- Capital burn/risk</div><div><br></div><div>Let=
ting 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 measurem=
ent. This mechanism I&#39;m proposing is measurable completely en-protocol =
and doesn&#39;t require trust in institutions that fork futures would. Addi=
tionally it could be an auxiliary=C2=A0feature of the soft fork deployment =
scheme chosen making it something you could neatly package all together wit=
h the deployment itself.</div><div><br></div><div>There are many potential =
tweaks to the design I propose above:</div><div>1. Do we include a notion o=
f negative signaling (allowing for the possibility of rejection)</div><div>=
2. Do we make it such that miner signaling must be congruent with &gt;X% of=
 transactions, where congruence is that the signal must match any non-neutr=
al signal of transaction.</div><div><br></div><div>Some anticipated objecti=
ons:</div><div><br></div><div>1. signaling 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 th=
ing to say and is breeding ground for abuse in the form of certain people m=
aking the unsubstantiated claim that consensus does or does not exist for a=
 particular initiative</div><div><br></div><div>2. This is just a proposal =
for &quot;pay to play&quot;, we should not let the wealthy make consensus d=
ecisions.</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 such a way where not only do they no=
t &quot;lose ammunition&quot; in the process of campaigning, but actually a=
ccrue it, creating really bad long-term balances of power.</div><div><br></=
div><div>3. Enforcing this proposal requires 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&#39;d like to even discuss whether o=
r not it&#39;s a good idea.</div><div><br></div><div>4. This gives CoinJoin=
 pool operators and L2 protocol implementations power over deciding consens=
us.</div><div>- I see this as an improvement over the status quo</div><div>=
<br></div><div>5. This encourages &quot;spam&quot;</div><div>- If you pay t=
he 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 th=
is afford=C2=A0us a better view into consensus than we have today?</div><di=
v>- Can it be gamed to give us a *worse* view into consensus? How?</div><di=
v>- Does it measure the right thing? If not, what do you think is the right=
 thing to measure? (assuming we could)</div><div>- Should I write a BIP spe=
c&#39;ing this out in detail?</div><div><br></div><div>Cheers,</div><div>Ke=
agan</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>

--000000000000c59c9c05dd9a1050--