path: root/86/b393270acb476b8070cc38f1617a64ddc75a1c

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E5A87C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 17:54:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CBBA2403FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 17:54:31 +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: 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 Rav9JMR0h9jM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 17:54:30 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 1F5E940126
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 17:54:30 +0000 (UTC)
Received: by mail-lj1-x231.google.com with SMTP id q185so3672658ljb.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 10:54:29 -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;
 bh=sPmbio+1Ya3liDyYq7b0pHy+58aBWl6/SqUTHF2tYG4=;
 b=OlYSwjcKlvPTrX9zLMbo+KNF2X74b+cX+wa6qSQIsMGJ0b1na8nOGUq+xnnBKsSKED
 bZHe7Oh0NlfXuUu2yDb7O/nSub9eKQ0qBcqDcMkpG5voxqnbq5U9FuI+yyNiuvlbGL9K
 O7YOsGLelF6cB/tHJ3JoNqAZk/BXc8JZP2Y66trtUKtzhlD6ZsoU/6AAL7qaAbE6IbOL
 j7+TsLqx2CqvrE1N4JF4r6e+UIj/Ky+IsVxhHEuHvdBL+aG3K+dHDcQVZIOz9/+qPJ73
 FRjfCl47rK0BORq3bTjmlDJ4hDnhGiETgDRcSQ+ZTwzgYQTAAVn9y6+r9HGLF99otoih
 072Q==
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=sPmbio+1Ya3liDyYq7b0pHy+58aBWl6/SqUTHF2tYG4=;
 b=eoKCEyfntjoDKkAm1AtfliqJZC7P2zmaFiEOv5sRGWRoODzujmsUNIIq7Il9K0GEdk
 BsTYEkty9bYwjNCVNUUEj7Kbz489+5bh7YRLTWYPJ99jePAvZsD///0WgI9Lq+GJ0l7c
 RyicM+VUW+M/71oCP+XorJARTMTmZF1iEDfQJjC8SuM7Amq6jGuPRKG+bSwaywkazHAL
 vHgLFwHATYnGaDYLraCKDXVruVTBHZee4rClha+TmhFYNcTWpzt8UGxGLUIeHj1EH1vC
 TvJX3FjxsCjElhfoRWP+Z4uAOrfGeVIsNs1OlwrLkodN2NZWeCBFgxZsDF3u+ihVRxf8
 I7Nw==
X-Gm-Message-State: AOAM532kK9Eam3Z06maau6+vMnosiMv/msetUjNsqQsKJnd/kkOol4Bf
 dhywDXcSJTX7iffgp8EymyoEEfZ/24tj5T/u/tq9OIIv
X-Google-Smtp-Source: ABdhPJxddoZURXbaSBLmdWmn/CIyHCJvh5r6fFNuS/iYL3wICf9aN56k2o+dyStbNPkM7eDRDI/CASEatt6kDu8T1hY=
X-Received: by 2002:a05:651c:1258:b0:24f:1050:fd2 with SMTP id
 h24-20020a05651c125800b0024f10500fd2mr11389330ljh.295.1651082067648; Wed, 27
 Apr 2022 10:54:27 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
In-Reply-To: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Wed, 27 Apr 2022 10:54:16 -0700
Message-ID: <CAD5xwhi7Hj6nfazbfeqH_WhMfOcf5vc4QSKKRBL9dfWXwUJ8Bw@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002325b905dda6807e"
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 17:54:32 -0000

--0000000000002325b905dda6807e
Content-Type: text/plain; charset="UTF-8"

Generally speaking, I'm not too fond of these mechanisms, for reasons
others have expounded upon, but I will point out the following:

Taproot means that top-level keys can be used in a ring signature scheme to
collect coin votes from, e.g., all individual coins above a certain value
at a certain time without revealing the particulars of who signed.

This capability helps with some of the chainalysis concerns.

However, note that many thoughtful individuals do not currently have any
taproot outputs on mainchain AFAIK because wallets are not yet 'upgraded',
so it's more of a future possibility.

One thing that might be nice is if there were a way to sign with a NUMS
point for ring signature purposes, but not for transactions. Otherwise if
NUMS points are common these ring signatures protocols might not be too
useful for collecting signals (even if they remain useful for covering a
set including the NUMS pointed tr outs).

--
@JeremyRubin <https://twitter.com/JeremyRubin>

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

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Generally=C2=A0speaking, =
I&#39;m not too fond of these mechanisms, for reasons others have expounded=
 upon, but I will point out the following:</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">Taproot means that top-lev=
el keys can be used in a ring signature scheme to collect coin votes from, =
e.g., all individual coins above a certain value at a certain time without =
revealing the particulars of who signed.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">This capability helps with s=
ome of the chainalysis concerns.</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">However, note that many thoughtful i=
ndividuals do not currently have any taproot outputs on mainchain AFAIK bec=
ause wallets are not yet &#39;upgraded&#39;, so it&#39;s more of a future p=
ossibility.</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">One thing that might be nice is if there were a way to si=
gn with a NUMS point for ring signature purposes, but not for transactions.=
 Otherwise if NUMS points are common these ring signatures protocols might =
not be too useful for collecting signals (even if they remain useful for co=
vering a set including the NUMS pointed tr outs).</div><br clear=3D"all"><d=
iv><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" ta=
rget=3D"_blank">@JeremyRubin</a><br></div></div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022=
 at 1:12 PM Keagan McClelland via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi a=
ll,<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 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 breakdown in civ=
ility around this debate is that because we don&#39;t have a means of measu=
ring user support for proposed sof-fork changes, it invariably devolves int=
o people claiming that their circles support/reject a proposal, AND that th=
eir 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 on=
e point or another said &quot;I would support activation of ____ if there w=
as consensus 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 sa=
ying &quot;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 o=
f 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 h=
ave any influence over what rulesets get activated or don&#39;t. As such &q=
uot;miner signaling&quot; is consistently devalued as a signal for market d=
emand. 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 on=
ly 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 mea=
sure User Support for a proposed rule change?</div><div><br></div><div>I&#3=
9;ve had 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 activat=
ion that are under consideration involve miner signaling in one form or ano=
ther. 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 ser=
vants of user demands, this should be in alignment with how people want Bit=
coin to behave.</div><div><br></div><div>Currently, the only means users ha=
ve 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 co=
mbine these in such a way that transactions themselves can signal for upgra=
de. 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 cou=
ld 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 blo=
ck that does not signal in the affirmative<br>- A transaction that is NOT s=
ignaling MAY be included in a block regardless of that block&#39;s signalin=
g vector</div><div>- (Optional) A transaction signaling in the negative MUS=
T 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-resi=
stant influence over miner decisions. If a miner cannot collect the fees fo=
r a transaction without signaling, the user&#39;s fee becomes active=C2=A0e=
conomic pressure for the miner to signal (or not, if we include some varian=
t 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 can pay fo=
r 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, an=
d any &quot;real&quot; view into what social consensus looks like MUST be s=
ybil resistant:</div><div><br></div><div>- Hashpower</div><div>- Proof of p=
ersonhood (KYC)<br>- Capital burn/risk</div><div><br></div><div>Letting has=
hpower decide this is the thing that is currently contentious, KYC is dead =
on arrival both on technical and social grounds, which really just leaves s=
ome means of getting capital into the process of consensus measurement. Thi=
s mechanism I&#39;m proposing is measurable completely en-protocol and does=
n&#39;t require trust in institutions that fork futures would. Additionally=
 it could be an auxiliary=C2=A0feature of the soft fork deployment scheme c=
hosen making it something you could neatly package all together with the de=
ployment itself.</div><div><br></div><div>There are many potential tweaks t=
o the design I propose above:</div><div>1. Do we include a notion of negati=
ve 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 transac=
tions, where congruence is that the signal must match any non-neutral signa=
l of transaction.</div><div><br></div><div>Some anticipated objections:</di=
v><div><br></div><div>1. signaling isn&#39;t voting, no deployment should b=
e made without consensus first.</div><div>- yeah well we can&#39;t currentl=
y measure consensus right now, so that&#39;s not a super helpful thing to s=
ay and is breeding ground for abuse in the form of certain people making th=
e unsubstantiated claim that consensus does or does not exist for a particu=
lar initiative</div><div><br></div><div>2. This is just a proposal for &quo=
t;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=
 making. But the status quo seems even worse where we let publicly influent=
ial people decide consensus in such a way where not only do they not &quot;=
lose ammunition&quot; in the process of campaigning, but actually accrue 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 consi=
der how 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 op=
erators and L2 protocol implementations power over deciding consensus.</div=
><div>- I see this as an improvement over the status quo</div><div><br></di=
v><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 biggest question I&#39;d l=
ike to pose to the=C2=A0forum is:</div><div>- Does a scheme like this affor=
d=C2=A0us a better view into consensus 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 not, what do you think is the right thing t=
o measure? (assuming we could)</div><div>- Should I write a BIP spec&#39;in=
g this out in detail?</div><div><br></div><div>Cheers,</div><div>Keagan</di=
v></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>

--0000000000002325b905dda6807e--