path: root/32/6ec67878f6c885821695d8d25d77000c08ad6c

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EF0B6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 19:37:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CDA9C40275
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 19:37:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id EE8WXz3cRjjy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 19:37:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [IPv6:2a00:1450:4864:20::436])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C3A1C40131
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 19:37:20 +0000 (UTC)
Received: by mail-wr1-x436.google.com with SMTP id q23so13990579wra.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 12:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=PgKZQEX5Bdp886xir39hK4fyh1Nxlm4KtxTvddbk8Mc=;
 b=Ako/6/O2o92YXZxSX4ElXea19K2T36M/F1zuS7zQFU2j65V9w6ysBvRySyxWC+xoHZ
 /IVCpxrYPlTPk6FeUocRLd8DlkJOt3MaF0bZCkbcxKAR3l7dHJyqC6PjwF7eHBgzYRVX
 U51FY45zeTxQwsrQLBKR00OyqC76Igl5vG9fh4VGyV/Kd2YNrHB57gD/KKdheYi4BOqI
 2asG5vzNriHkT8T7RzBduCQhb8M+Wc5fhOMPPU1KEjGXU8/6qG4FOHh6IPwj49ijJ2rw
 lJNQo24lKRX15XEMsoEsvCFoMARjWOd+oFtnFT7E9m++nyn1ZXJSQlFauD2KxF/5ij2O
 EVOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=PgKZQEX5Bdp886xir39hK4fyh1Nxlm4KtxTvddbk8Mc=;
 b=Zh/aisDh2e1NwSS+zGL1/XZz7c2MFtsExFnu12WeahgQA7MsDbJCixgqiofWPaYF46
 Rw8NW21Ex6w4Ir9chh9yXCB6itfRHqYGFO/343YPG1tWSJ1IKelmOwYG+QqXl3rG51p8
 +EtRyhozKtpKSNdFCAfH0EVE6qg1PhkGLz09n5cVderigcBS9qEdCzx88NV+YN8nnXOi
 e/y+LplpqnnFq/99AlucOqllBtwt/Eap6AekQWOtJ2/e9ziAgOIv44azSEJx0tDbB9mr
 oYjUezXxGpE95KE1JapUBhhxlSlGNWaTlHgKsAOAnW9tEIzk3v4L1npMv4Y7P8DQOlo1
 ++ww==
X-Gm-Message-State: AOAM533otzgIpSgYCSDMQQvOvJ9U4B5OPxw3l50gbMXIIgloCH41HmxZ
 dUQThDOe+lFNpBRQrrZk1gYprJpUrhrlKlPFukdy+tDPVSc=
X-Google-Smtp-Source: ABdhPJxpjwT30G7/i3oUWqd63kKvORBC93qW8v6BPSCBj87QS7/X5/6HgMe4X6Fi4N8VqKM7KcaARp4n5KjTXZheCNk=
X-Received: by 2002:a5d:59af:0:b0:20a:e9e7:5c12 with SMTP id
 p15-20020a5d59af000000b0020ae9e75c12mr2240261wrr.572.1651001838312; Tue, 26
 Apr 2022 12:37:18 -0700 (PDT)
MIME-Version: 1.0
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Tue, 26 Apr 2022 13:37:07 -0600
Message-ID: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000189eff05dd93d240"
X-Mailman-Approved-At: Tue, 26 Apr 2022 20:12:02 +0000
Subject: [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: Tue, 26 Apr 2022 19:37:23 -0000

--000000000000189eff05dd93d240
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">Hi all,<div><br></div><div>Alongside the debate with CTV r=
ight now there&#39;s a second debate that was not fully hashed out in the a=
ctivation of Taproot. There is a lot of argument around what Speedy Trial i=
s or isn&#39;t, what BIP8 T/F is or isn&#39;t etc. A significant 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 sof-fork changes, it in=
variably 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.</div><div><br></div><div>It seems everyone in=
 this forum has at one point or another said &quot;I would support activati=
on of ____ if there was consensus on it, but there isn&#39;t&quot;. This st=
atement, 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 dodg=
e this question by saying &quot;it&#39;s obvious&quot;, but the reality is =
that it fundamentally isn&#39;t. My bubble has a different &quot;obvious&qu=
ot; 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 coul=
d 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 foll=
owing 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 st=
ands right now the only signal we have to work with is miner signaling, whi=
ch 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><di=
v><br></div><div>I&#39;ve had this idea floating around in the back of my h=
ead for a while, and I&#39;d like to solicit some feedback here. Currently,=
 all forms of activation that are under consideration involve miner signali=
ng in one form or another. What if we could make it such that users could m=
ore directly pressure miners to act on their behalf? After all, if miners a=
re but the humble servants of user demands, this should be in alignment wit=
h how people want Bitcoin to behave.</div><div><br></div><div>Currently, th=
e 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 inclu=
sion. 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 present=
ly ignored. If we could devise a mapping between some of those free bits, a=
nd the signaling bits in the block header, it would be possible to have rul=
es 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 tran=
saction that is NOT signaling MAY be included in a block regardless of that=
 block&#39;s signaling vector</div><div>- (Optional) A transaction signalin=
g in the negative MUST NOT be included in a block that signals in the affir=
mative</div><div><br></div><div>Under this set of conditions, a user has th=
e means of sybil-resistant influence over miner decisions. If a miner canno=
t 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 w=
e 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 net=
work at large.</div><div><br></div><div>Some may take issue with the idea t=
hat people can pay for the outcome they want and may try to compare a metho=
d like this to Proof of Stake, but there are only 3 sybil resistant mechani=
sms I am aware of, and any &quot;real&quot; view into what social consensus=
 looks like MUST be sybil resistant:</div><div><br></div><div>- Hashpower</=
div><div>- Proof of personhood (KYC)<br>- Capital burn/risk</div><div><br><=
/div><div>Letting hashpower decide this is the thing that is currently cont=
entious, KYC is dead on arrival both on technical and social grounds, which=
 really just leaves some means of getting capital into the process of conse=
nsus measurement. This mechanism I&#39;m proposing is measurable completely=
 en-protocol and doesn&#39;t require trust in institutions that fork future=
s would. Additionally it could be an auxiliary=C2=A0feature of the soft for=
k deployment scheme chosen making it something you could neatly package all=
 together with the deployment itself.</div><div><br></div><div>There are ma=
ny potential tweaks to the design I propose above:</div><div>1. Do we inclu=
de a notion of negative signaling (allowing for the possibility of rejectio=
n)</div><div>2. Do we make it such that miner signaling must be congruent w=
ith &gt;X% of transactions, where congruence is that the signal must match =
any non-neutral signal of transaction.</div><div><br></div><div>Some antici=
pated objections:</div><div><br></div><div>1. signaling isn&#39;t voting, n=
o 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 sup=
er helpful thing to say and is breeding ground for abuse in the form of cer=
tain people making the unsubstantiated claim that consensus does or does no=
t exist for a particular initiative</div><div><br></div><div>2. This is jus=
t a proposal for &quot;pay to play&quot;, we should not let the wealthy mak=
e consensus decisions.</div><div>- I agree that wealth should not be able t=
o 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 on=
ly do they not &quot;lose ammunition&quot; in the process of campaigning, b=
ut actually accrue it, creating really bad long-term balances of power.</di=
v><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 disc=
uss whether or not it&#39;s a good idea.</div><div><br></div><div>4. This g=
ives CoinJoin pool operators and L2 protocol implementations power over dec=
iding consensus.</div><div>- I see this as an improvement over the status q=
uo</div><div><br></div><div>5. This encourages &quot;spam&quot;</div><div>-=
 If you pay the fees, it&#39;s not spam.</div><div><br></div><div>The bigge=
st question I&#39;d like to pose to the=C2=A0forum is:</div><div>- Does a s=
cheme like this afford=C2=A0us a better view into consensus than we have to=
day?</div><div>- Can it be 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 measure? (assuming we could)</div><div>- Should I wr=
ite a BIP spec&#39;ing this out in detail?</div><div><br></div><div>Cheers,=
</div><div>Keagan</div></div>

--000000000000189eff05dd93d240--