path: root/79/9c234d9d8bbd035430768d06db50f3f1e1edb2

Return-Path: <nadav@shesek.info>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 431AAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 00:17:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1B79760F0A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 00:17:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.597
X-Spam-Level: 
X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id x32d0DcC_Uqe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 00:17:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [IPv6:2607:f8b0:4864:20::d2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4EE2A60ECE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 00:17:10 +0000 (UTC)
Received: by mail-io1-xd2f.google.com with SMTP id i20so3289174ion.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 17:17:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=hkIL7z/VRAqC8IOI/zYN4nFiHDS6eZ1jbbI8q85nvhk=;
 b=bwpczij/RCkYOA/y7lE+Ksmt9ISpCxSS32bPR7QNdalnbuFzbiBSutqk6DX+qrmHmK
 C+u+5rCEyqfUUMahKJ3w1FXMYp6j4+Q7+J1iCMpNT26s8dawBcNG+Qocd9jsw0zz6HN+
 o4lZcCjO+ppNqLfb/fZwFyynYwkNph2FOYoE0=
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;
 bh=hkIL7z/VRAqC8IOI/zYN4nFiHDS6eZ1jbbI8q85nvhk=;
 b=kQvcCipZdHLju/+fMLxAh/cWyRljBSN86+fupCwE0xHEtb1yaLFWhwe9tUla1nbmIp
 2hTcSG8w4hwiYbNUZLYGV0ZnZMv2cFCIN1vhoc5OhgM50Z4/k/s1ZOyuQa8W4B26fhap
 9IaAePn7OAI1JD8PDWgIpL2e1G+hDKwjZ83NSiVZGLYp2mSUiXVbJf++MAuy0CqJnNCO
 DapkQu9WIuTJp3OW8OvOKMi9OQ5CpAu6JEv4raSWEuT23cio9PNWYe6gcI6lsg6eUrNT
 ueg5kyNZNm4M22LWodSQyIpfzA3VzGBAOlixUNWnf6oQNUxAR6iuzcowndEuAv6gJ+uG
 ACsw==
X-Gm-Message-State: AOAM532shwhAGIRp2hcCaQeuDwangbsc1gC1xQPpIDyHqnEl2ytpqFby
 LavN8k9pbHq5lqjCB6T2RFfhP+oOyeZFgdWRP8rzvmxX6YnAaafp
X-Google-Smtp-Source: ABdhPJwBvs7mRe0KOrLQNGgMqDrOXUCXQo5RFm0mzwQAVYLihl0mA0IvIg6ujmRr2XsnP+1qNb8OWJCopi9fYmimjyc=
X-Received: by 2002:a05:6602:25c1:b0:653:12d3:fb53 with SMTP id
 d1-20020a05660225c100b0065312d3fb53mr12966135iop.52.1651105029066; Wed, 27
 Apr 2022 17:17:09 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
In-Reply-To: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Thu, 28 Apr 2022 03:16:57 +0300
Message-ID: <CAGXD5f2e6o0b5E_WDEs8UZ63Oc14yK4rDE+9YAyxApb2Zo_How@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000beade905ddabd8ae"
X-Mailman-Approved-At: Thu, 28 Apr 2022 08:46:40 +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: Thu, 28 Apr 2022 00:17:12 -0000

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

Back in the 2017 block size wars I brought up the idea [0] of using
time-locked-weighted voting as a mechanism to gauge community/hodler
sentiment (lived on testnet for awhile at https://hodl.voting [1]).

Basically, the user locks up some bitcoins with an OP_CSV while committing
to some statement (using a pay-to-contract-hash construct in my
implementation[2]). Votes are then weighted as <lock duration> x <locked
btc amount>.

This has some interesting advantages over the more naive coin weighting
scheme used at the time (Bitcoinocracy [3]):

1. There's a real cost attached to voting, in the form of lost liquidity
and losing the ability to sell. The handicap principle suggests that this
makes for more reliable signaling, getting people to put more thought and
consideration into their vote (and whether they really care/know enough
about the issue to vote on it at all).
2. It shows that the voter has a long-term interest in the value of bitcoin
(and stands to lose if bitcoin is harmed), and gives more influence to
long-term hodlers that possess strong confidence in bitcoin.
3. Custodians don't get disproportionate voting power with their customers'
funds (not without getting themselves into fractional reserve, at least).
5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

A drawback is that in a chain-split scenario, you cannot use these bitcoins
to influence the markets (participate in futures markets, sell the side of
the split you want to see die off etc). But some people might not agree to
lose self-custody over their coins in order to do that, while with
time-weighted voting they can retain full self-custody. Or maybe they're
only willing to risk some X% on centralized futures markets, and still have
aside some Y% to allocate for timelocking.

To clarify, I don't really see this as 'voting' despite calling it that.
I'm definitely not advocating to use this as some authoritative
decision-making voting mechanism or as part of an activation mechanism,
only possibly as one more market signal to look at among many.

As for the proposal in the OP, it could be argued that mining fees are not
a highly reliable signal because users have to pay them anyway when
transacting, which makes the voting itself zero-cost (perhaps except for
waiting some more time to get it confirmed?). And as others have mentioned,
this gives influence primarily to transactors (the tx volume by exchanges
and payment processors easily eclipses that of end users) and not to
hodlers (while my idea does the exact opposite, so maybe makes sense to use
both?).

shesek

[0]
https://bitcoinmagazine.com/markets/hodlvoting-voting-your-bitcoins-better
[1] http://web.archive.org/web/20170710161455/https://hodl.voting/
[2] https://github.com/shesek/proof-of-hodl (hackathon grade code)
[3] Seems like a version of it now lives at
https://bitcoinocracy.herokuapp.com/

On Tue, Apr 26, 2022 at 11: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
>

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

<div dir=3D"ltr"><div>Back in the 2017 block size wars I brought up the ide=
a [0] of using time-locked-weighted voting
 as a mechanism to gauge community/hodler sentiment (lived on testnet for a=
while at <a href=3D"https://hodl.voting">https://hodl.voting</a> [1]).</div=
><div><br></div><div>Basically, the user locks up some
 bitcoins with an OP_CSV while committing to some statement (using a=20
pay-to-contract-hash construct in my implementation[2]). Votes are then wei=
ghted as=20
&lt;lock duration&gt; x &lt;locked btc amount&gt;.</div><div><br></div><div=
>This has some interesting advantages over the more naive coin weighting sc=
heme used at the time (<span style=3D"font-family:arial,sans-serif">Bitcoin=
ocracy</span> [3]):<br></div><div><br></div><div>1. There&#39;s a real cost=
 attached to voting, in the form of lost liquidity and losing the ability t=
o sell. The handicap principle suggests that this makes for more reliable s=
ignaling, getting people to put more thought and consideration into their v=
ote (and whether they really care/know enough about the issue to vote on it=
 at all).</div><div>2. It shows that the voter has a long-term interest in =
the value of bitcoin (and stands to lose if bitcoin is harmed), and gives m=
ore influence to long-term hodlers that possess strong confidence in bitcoi=
n.<br>3. Custodians don&#39;t get disproportionate voting power with their =
customers&#39; funds (not without getting themselves into fractional reserv=
e, at least).<br>5. Selling your vote if you&#39;re disinterested in the ou=
tcome isn&#39;t a no-brainer like in the naive scheme.</div><div><br></div>=
<div>A drawback is that in a chain-split scenario, you cannot use these=20
bitcoins to influence the markets (participate in futures markets, sell=20
the side of the split you want to see die off etc). But some people=20
might not agree to lose self-custody over their coins in order to do that, =
while with time-weighted voting they can retain full self-custody. Or maybe=
 they&#39;re only willing to risk some X% on centralized futures markets, a=
nd still have aside some Y% to allocate for timelocking.<br></div><div><br>=
</div><div>To clarify, I don&#39;t really see this as &#39;voting&#39; desp=
ite calling it that. I&#39;m definitely not advocating to use this as some =
authoritative decision-making voting mechanism or as part of an activation =
mechanism, only possibly as one more market signal to look at among many.</=
div><div><br></div><div>As for the proposal in the OP, it could be argued t=
hat mining fees are not a highly reliable signal because users have to pay =
them anyway when transacting, which makes the voting itself zero-cost (perh=
aps except for waiting some more time to get it confirmed?). And as others =
have mentioned, this gives influence primarily to transactors (the tx volum=
e by exchanges and payment processors easily eclipses that of end users) an=
d not to hodlers (while my idea does the exact opposite, so maybe makes sen=
se to use both?).<br></div><div><br></div><div>shesek<br></div><div><br></d=
iv><div><div>[0] <a href=3D"https://bitcoinmagazine.com/markets/hodlvoting-=
voting-your-bitcoins-better">https://bitcoinmagazine.com/markets/hodlvoting=
-voting-your-bitcoins-better</a></div></div><div>[1] <a href=3D"http://web.=
archive.org/web/20170710161455/https://hodl.voting/">http://web.archive.org=
/web/20170710161455/https://hodl.voting/</a></div><div>[2] <a href=3D"https=
://github.com/shesek/proof-of-hodl">https://github.com/shesek/proof-of-hodl=
</a> (hackathon grade code)</div><div>[3] Seems like a version of it now li=
ves at <a href=3D"https://bitcoinocracy.herokuapp.com/">https://bitcoinocra=
cy.herokuapp.com/</a><br></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 11:12 PM Keagan McCl=
elland via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote 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"ltr">Hi all,<div>=
<br></div><div>Alongside the debate with CTV right now there&#39;s a second=
 debate that was not fully hashed out in the activation of Taproot. There i=
s 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 breakdown in civility ar=
ound this debate is that because we don&#39;t have a means of measuring use=
r support for proposed sof-fork changes, it invariably devolves into people=
 claiming that their circles support/reject a proposal, AND that their circ=
les are more broadly representative 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 would support activation of ____ if there was conse=
nsus on it, but there isn&#39;t&quot;. 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 &qu=
ot;it&#39;s obvious&quot;, but the reality is that it fundamentally isn&#39=
;t. My bubble has a different &quot;obvious&quot; answer than any of yours.=
</div><div><br></div><div>Secondly, due to the trauma of the block size war=
s, 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;mine=
r signaling&quot; is consistently 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 aware that they have the strong incentive that they =
understand market demand. Nevertheless, as it stands right now the only sig=
nal we have to work with is miner signaling, which I think is rightly frust=
rating to a lot of people.</div><div><br></div><div>So how can we measure U=
ser Support for a proposed rule change?</div><div><br></div><div>I&#39;ve h=
ad this idea floating around in the back of my head for a while, and I&#39;=
d like to solicit some feedback here. Currently, all forms of activation th=
at are under consideration involve miner signaling in one form or another. =
What if we could make it such that users could more directly pressure miner=
s 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 t=
o behave.</div><div><br></div><div>Currently, the only means users have of =
influencing miner decisions are A. rejection of blocks that don&#39;t follo=
w 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 &quot;free&quot; bits in the=
 version field of a transaction that are presently ignored. If we could dev=
ise a mapping between some of those free bits, and the signaling bits in th=
e block header, it would be possible to have rules as follows:<br><br>- A t=
ransaction signaling in the affirmative MUST NOT be included in a block tha=
t does not signal in the affirmative<br>- A transaction that is NOT signali=
ng MAY be included in a block regardless of that block&#39;s signaling vect=
or</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 conditions, a user has the means of sybil-resistant =
influence over miner decisions. If a miner cannot collect the fees for a tr=
ansaction without signaling, the user&#39;s fee becomes active=C2=A0economi=
c pressure for the miner to signal (or not, if we include some variant of t=
he negative clause). In this environment, miners could have a better view i=
nto what users do want, as would the Bitcoin network at large.</div><div><b=
r></div><div>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 Sta=
ke, but there are only 3 sybil resistant mechanisms I am aware of, and any =
&quot;real&quot; view into what social consensus looks like MUST be sybil r=
esistant:</div><div><br></div><div>- Hashpower</div><div>- Proof of personh=
ood (KYC)<br>- Capital burn/risk</div><div><br></div><div>Letting hashpower=
 decide this is the thing that is currently contentious, KYC is dead on arr=
ival both on technical and social grounds, which really just leaves some me=
ans of getting capital into the process of consensus measurement. This mech=
anism I&#39;m proposing is measurable completely en-protocol and doesn&#39;=
t require trust in institutions that fork futures would. Additionally it co=
uld be an auxiliary=C2=A0feature of the soft fork deployment scheme chosen =
making it something you could neatly package all together with the deployme=
nt 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 of negative sig=
naling (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-neutral signal of t=
ransaction.</div><div><br></div><div>Some anticipated objections:</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 meas=
ure consensus right now, so that&#39;s not a super helpful thing to say and=
 is breeding ground for abuse in the form of certain people making the unsu=
bstantiated claim that consensus does or does not exist for a particular in=
itiative</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 decisions.</div=
><div>- I agree that wealth should not be able to strong-arm decision makin=
g. But the status quo seems even worse where we let publicly influential pe=
ople decide consensus in such a way where not only do they not &quot;lose a=
mmunition&quot; in the process of campaigning, but actually accrue it, crea=
ting really bad long-term balances of power.</div><div><br></div><div>3. En=
forcing 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 ho=
w to make this happen, I&#39;d like to even discuss whether or not it&#39;s=
 a good idea.</div><div><br></div><div>4. This gives CoinJoin pool operator=
s and L2 protocol implementations power over deciding consensus.</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 the fees, it&#3=
9;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 consensus than we have today?</div><div>- Can it b=
e gamed to give us a *worse* view into consensus? How?</div><div>- Does it =
measure the right thing? If not, what do you think is the right thing to me=
asure? (assuming we could)</div><div>- Should I write a BIP spec&#39;ing th=
is 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>

--000000000000beade905ddabd8ae--