path: root/db/15a16f69b5ea5988d73f89d3678681230ec57f

Return-Path: <kanzure@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9104CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 20:49:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 68DAA40A8E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 20:49:03 +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 HYTmywcFMXpn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 20:48:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [IPv6:2a00:1450:4864:20::131])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5730E40A89
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 20:48:59 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id w19so34012716lfu.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 13:48:59 -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=ergbgkwIuWkdhapFaP8qbu9BO4gm5DIycta+EVKrCNQ=;
 b=YQgVg5pjOiQFFsqLWFI7ZPhzCoLbKB1z19VAekZAXP2eiFJ2raglh5rpgjopSXEIv3
 6X+UskwG7uQEb0bqtVziDBgcNvpODZ8dM2yPschBc34vWyXIY+HbwTPEEvVOarojljR0
 XdnREUbW6WQxwk/aXiLxKfZZMS+nCS1KLvm8xqR/dRftygYmyc7eVFILwsxs1B+JXgd6
 VZz/dQiUbV5LlkRXj/XtsZGS50FGE7wMK+vDXmzJDdrr1asVbruk9MzhrRdrRhvVvh8g
 pA3EKGqx6Y6AsAYdWvQkUNKxpPpkUkl/kQTYaGlmcvZz7dgcxuga2u/mz1wj4Qly7zTS
 ey7w==
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=ergbgkwIuWkdhapFaP8qbu9BO4gm5DIycta+EVKrCNQ=;
 b=weCRAuqRtfW33otVc818lq47iZrqt2ncDJc6WJv0lnSW4cBt6VYyvb68bu5m3Rwi+J
 kS7qM7cXXK2fYddOZmLeIptRBBrSuDBz1jWzEFATU5XsMNHxvRyoL4a5PNho/3CK2w0y
 CXv1rjxluA+b34Nvtq4+j6etnCHJZ5cmAyEJFuUat+mqtEkOpRgiZcDI8CcJb94lDTyW
 KvHWoFVDqAaKq13ah/wZ1bSuiMP5oYUOoOW/x2EY5u0Wp+JxaRe0QI9GH2HxrQcVoP/L
 osbJZlG47FTBAI2y11Gv5H7kw9Cg+aw2DALratHZLSdFooBAiHC1ZDZyW3+Lxfi/sNkp
 mLkQ==
X-Gm-Message-State: AOAM531tGArTSLoLWwuOrnHDizoKFn81Mdsune1DK3lvUUf1ymxDLkr2
 99R+S+lo9WOdNAwVGtLfzbZuJyS64fWZv+rBYdg=
X-Google-Smtp-Source: ABdhPJzn7RTZROq4OHR6jmRsZvRA8pQpQEXVEGYHjOWQIacbiP0KF1rmK08g2AFolvnCGfhQPlH6g5TvvbSroMZv1Qg=
X-Received: by 2002:a05:6512:2346:b0:471:b3cc:ce21 with SMTP id
 p6-20020a056512234600b00471b3ccce21mr17470784lfu.480.1651006136922; Tue, 26
 Apr 2022 13:48:56 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
In-Reply-To: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Tue, 26 Apr 2022 15:39:44 -0500
Message-ID: <CABaSBayKH__f_ahUUiDt2SiKik9aNLR1AXtG9RtWrFmTLP5qKw@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000050378a05dd94d259"
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: Tue, 26 Apr 2022 20:49:03 -0000

--00000000000050378a05dd94d259
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">You may be interested in these posts on transaction signal=
ling:<br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2017-April/014193.html">https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2017-April/014193.html</a><br><a href=3D"https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2017-April/014202.html">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2017-April/014202.html</a><br><a href=3D"h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html=
">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.h=
tml</a><br><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>A=
longside 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 argum=
ent 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 around this debate=
 is that because we don&#39;t have a means of measuring user support for pr=
oposed sof-fork changes, it invariably devolves into people claiming that t=
heir circles support/reject a proposal, AND that their circles are more bro=
adly 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 consensus on it, but =
there isn&#39;t&quot;. This statement, in order to be true, requires that t=
here exist a set of conditions that would convince you that there is consen=
sus. People have tried to dodge this question by saying &quot;it&#39;s obvi=
ous&quot;, but the reality is that it fundamentally isn&#39;t. My bubble ha=
s a different &quot;obvious&quot; answer than any of yours.</div><div><br><=
/div><div>Secondly, due to the trauma of the block size wars, no one wants =
to utter a statement that could imply that miners have any influence over w=
hat 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 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 signal we have to wor=
k with is miner signaling, which I think is rightly frustrating to a lot of=
 people.</div><div><br></div><div>So how can we measure User Support for a =
proposed rule change?</div><div><br></div><div>I&#39;ve had this idea float=
ing 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 that are under consi=
deration involve miner signaling in one form or another. What if we could m=
ake 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, t=
his should be in alignment with how people want Bitcoin to behave.</div><di=
v><br></div><div>Currently, the only means users have of influencing miner =
decisions are A. rejection of blocks that don&#39;t follow rules and B. pay=
ing fees for transaction inclusion. I suggest we combine these in such a wa=
y 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 devise a mapping betw=
een 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 signali=
ng 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>- (Op=
tional) A transaction signaling in the negative MUST NOT be included in a b=
lock that signals in the affirmative</div><div><br></div><div>Under this se=
t of conditions, a user has the means of sybil-resistant influence over min=
er decisions. If a miner cannot collect the fees for a transaction without =
signaling, the user&#39;s fee becomes active=C2=A0economic pressure for the=
 miner to signal (or not, if we include some variant of the negative clause=
). In 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 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 &quot;real&quot; v=
iew into what social consensus looks like MUST be sybil resistant:</div><di=
v><br></div><div>- Hashpower</div><div>- Proof of personhood (KYC)<br>- Cap=
ital burn/risk</div><div><br></div><div>Letting hashpower decide this is th=
e thing that is currently contentious, KYC is dead on arrival both on techn=
ical and social grounds, which really just leaves some means of getting cap=
ital into the process of consensus measurement. This mechanism I&#39;m prop=
osing is measurable completely en-protocol and doesn&#39;t require trust in=
 institutions that fork futures would. Additionally it could be an auxiliar=
y=C2=A0feature of the soft fork deployment scheme chosen making it somethin=
g you could neatly package all together with the deployment itself.</div><d=
iv><br></div><div>There are many potential tweaks to the design I propose a=
bove:</div><div>1. Do we include a notion of negative signaling (allowing f=
or 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 transaction.</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 measure consensus righ=
t now, so that&#39;s not a super helpful thing to say and is breeding groun=
d for abuse in the form of certain people making 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 decisions.</div><div>- I agree th=
at wealth should not be able to strong-arm decision making. But the status =
quo seems even worse where we let publicly influential people decide consen=
sus 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 lo=
ng-term balances of power.</div><div><br></div><div>3. Enforcing this propo=
sal 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 hap=
pen, 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 operators 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 encourage=
s &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 like to pose to the=C2=A0=
forum is:</div><div>- Does a scheme like this afford=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 th=
ing? If not, what do you think is the right thing to measure? (assuming we =
could)</div><div>- Should I write a BIP spec&#39;ing this out in detail?</d=
iv><div><br></div><div>Cheers,</div><div>Keagan</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">- Bryan<br><a href=3D"https://t=
witter.com/kanzure" target=3D"_blank">https://twitter.com/kanzure</a></div>=
</div>

--00000000000050378a05dd94d259--