path: root/3b/695db721f3b197c99d3ef643a0467d0053f189

Return-Path: <micaroni3@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 16104C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 08:04:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 042E360B04
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 08:04:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Iytpw1lfp0aW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 08:04:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [IPv6:2607:f8b0:4864:20::630])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B644560AEA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 08:04:30 +0000 (UTC)
Received: by mail-pl1-x630.google.com with SMTP id k4so3672612plk.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 01:04:30 -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=OvFqCFPt5m2vJXNnez8A4q76KTkQQu4Qi59zaN/+dRw=;
 b=NfL+e4KT0UOn5lGffqgasOQurITcPcU9yTMY9Sr0uJBt7u6nxin1eSA7IHNAh2eHhy
 o98Ec1svD5MfoKM5fuV8Cf6JTDWXmSYFlJLBJreDPwc0gWhg66Mqb0ykZEZqHrOzVJIk
 1jlLRHuZ8b5NGuEHKVUMpjXEiHIlwVAnIGtGkKwdXz0n9r67gQEI9L/5Bcd7ksLI8u4V
 dAcE0ZQLiM7VY6LrNKgw53fS8b4NcVpCY4gDFFxrXFEzgoLsI2QFV+2FCYFSNqjLaQ47
 Gfw/mYCGrbKFRHiHdp2JDFLxUCSmy3AaESazo3nWXkQpf4f36GjiCgj4tuuKQVke/GU1
 dFnA==
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=OvFqCFPt5m2vJXNnez8A4q76KTkQQu4Qi59zaN/+dRw=;
 b=JT180B0AVnZV2kA1NCkvFhkcjNxYLnmi0PVDH2DEuf42PnwGdoYhRm97RTHJA+8gqk
 CNQz8/LuJ0DzguJJR3K/RCMfJ3AwrFDhbzYhaK7a/RkRwKZEmJuCR25/2O29B2ubLw4A
 7HWp/z2tDZZcjNQtev63dmlEd8tnm891Hf1sPnKD/nCsZGijjQjsRUJGfU3pTqAdLwfO
 yTlmJBcbPBdVi9FGebO+Zb2nT6IjeWHxoc3T6l/SdLY21vBmX+e/FDQ+cat24sfcjROF
 aVZyEK8MlwHJI2uMhZxddQ346XcSde84auF9os/mS7U3RazZr1bh+Z3B+HZ38GE2BYQR
 Vf2g==
X-Gm-Message-State: AOAM533FnVOnyqc593K4vze2E91YA6iCSpbEbvPnCTHjI5CRE0N+aqyw
 37fqqlQrEhaPcVMWMoJlMOsR2nD/La+BhdTCBEI=
X-Google-Smtp-Source: ABdhPJxmBfTo9Z8nH8UpaJPjqPM6h68skfIZIZG1Y6FA5f7WmJB5Dl7dEntKRoOEEIu/btlrGtq0C1TftLkt+tTSrVo=
X-Received: by 2002:a17:902:cccc:b0:15a:30ec:2f56 with SMTP id
 z12-20020a170902cccc00b0015a30ec2f56mr32576227ple.169.1651133070010; Thu, 28
 Apr 2022 01:04:30 -0700 (PDT)
MIME-Version: 1.0
References: <CALeFGL2Orc6F567Wd9x7o1c5OPyLTV-RTqTmEBrGNbEz+oPaOQ@mail.gmail.com>
 <CAHvMVPQWkEN_tpwNwkVkPs9W=DsmkBxMfJfqAbv8JNPVxkfKkQ@mail.gmail.com>
 <CALeFGL3oV2c8cioak1-CfDxNp93wz1qwasYETTgkAY+C31Mbxw@mail.gmail.com>
In-Reply-To: <CALeFGL3oV2c8cioak1-CfDxNp93wz1qwasYETTgkAY+C31Mbxw@mail.gmail.com>
From: micaroni@gmail.com
Date: Thu, 28 Apr 2022 05:03:53 -0300
Message-ID: <CAHvMVPShYOJt80PhWKfMBoZ7JZzTXq1M-8csLzwheyQr8Ps_Dg@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001d6e4505ddb260c6"
X-Mailman-Approved-At: Thu, 28 Apr 2022 08:46:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 08:04:33 -0000

--0000000000001d6e4505ddb260c6
Content-Type: text/plain; charset="UTF-8"

Hi Keagan,

The worst case scenario is: no new proposals are accepted and the Bitcoin
remains the same. This is not so bad. I think a bad actor will usually want
to *add* (or remove) something that breaks. I don't know if the boycott of
new proposals is as effective in breaking Bitcoin. It means the more
important devs are not in full control, but they have the (kind of) power
of veto if they have really rational arguments. The most harm they can do
is delay things a little.

But remember: after all, everyone is free to fork the code, try to change
something and perhaps create undesirable splits in the network.


Felipe.


On Wed, Apr 27, 2022 at 3:32 PM Keagan McClelland <
keagan.mcclelland@gmail.com> wrote:

> Felipe,
>
> > For me, the consensus should follow the current line: discussions and
> tests carried out by experts. We all know that the most important devs have
> the most weight in discussions. And that's how it should be, because they
> understand far better than any other lowly mortal. Consensus simply means
> that there are not at least two or three important people opposing the idea
> with solid arguments. Is it very subjective and difficult? Yes. For sure.
> We all yearn for objective answers or methods. However, any method would
> fail. At the end, after numerous discussions and an apparent consensus, the
> objective answer and the real consensus will be obtained in the network, in
> the nodes upgrading. If there is a big war, the network will end up
> splitting in two, as it has in the past. To avoid any unwanted splits we
> discuss for exhaustion here in the list.
>
> This is essentially an admission that devs have control over the protocol.
> Users "having control" but deferring their judgement to devs is not
> meaningfully different than devs "having control". Many people have
> asserted, quite strongly, that this ought not be how Bitcoin governs
> itself. I myself am on the fence about what is practically possible or not.
> However, let's say that your supposition is correct. How would we protect
> against a corollary scenario where a dev has a proposal that looks great
> but has dark ends that no one notices yet, if the process for evaluation
> more or less is to defer to "the most important devs" expertise? Presumably
> we hash this out in forums like this, but in order to "override" the "most
> important devs" we have to have a way (formalized or not) of deciding when
> the "lesser experts" in aggregate have better judgement.
>
> Erik,
>
> > There are many challenges with on-chain voting, here are a few:
>
> This may be hair-splitting but I feel it important to clarify that my
> proposal isn't voting per se. Calling it that doesn't bug me, but the
> mechanics are meaningfully different than a simple tally vote which is the
> intuition that I think that term conveys. As Billy mentions this proposal
> actually requires that miners block signals from inclusion in the block if
> they themselves do not signal. I'm not necessarily claiming this is a
> superior design overall, however the "flaw" you point out is by design in
> this case. My goal in the proposal was really to give users a means of
> applying direct economic pressure to miners, who do inevitably play a role
> in BIP8/BIP9 activation procedure.
>
> Ryan,
>
> > - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
>
> Definitely a frightening proposition I hadn't considered. It does open up
> the possibility of tracking individual preferences and targeting of
> political opponents.
>
> >   - yuk, it's voting.
>
> I don't think the process of collecting information on user preference is
> in and of itself bad. Where I think Bitcoiners really want to avoid voting
> is this notion that 51% of the constituency can bully the other 49% into
> whatever they want. No part of my proposal suggests this, nor is it
> something I would want.
>
> -----
>
> I think there are a few questions surrounding the issue of soft fork
> activation. Perhaps it warrants zooming out beyond even what my proposal
> aims to solve. In my mind the most important questions surrounding this
> process are:
>
> 1. In an ideal world, assuming we could, with perfect certainty, know
> anything we wanted about the preferences of the user base, what would be
> the threshold for saying "this consensus change is ready for activation"?
>     1a. Does that threshold change based on the nature of the consensus
> change (new script type/opcode vs. block size reduction vs. blacklisting
> UTXOs)?
>     1b. Do different constituencies (end users, wallets, exchanges,
> coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
> maximum representation in this "threshold"?
> 2. Given an answer from #1, what tests can we devise to measure those
> levels of support directly? If we can't measure it directly, can we measure
> different indicators that would help us infer or solve for the knowledge we
> want?
> 3. Can any of the answers to #2 be "gamed"? I'm defining "game" here to
> mean that the measurement taken, diverges from the ground truth we are
> trying to get at in such a way that its divergence would be undetectable.
>
> If we do not answer these sorts of questions we can get technical
> consensus through this messy process, but when it comes to assessing user
> consensus, it is just going to devolve into dogma and demagoguery as we
> each have our own perceptions or agendas and there is no rigorous way for
> anyone to refute our claims. This would, again, be an admission that devs
> ultimately do make protocol decisions. Perhaps it's unavoidable and we are
> doomed to this painful process of arguing with one another until
> there's only one opinion left standing (either because of merit or just
> plain old grit). However, if this is the case, I don't think we can
> honestly claim that devs don't control the protocol (as a group).
>
> I don't think we will have broad agreement on #1 as it is ultimately a
> value judgement and even the most intellectually honest people in Bitcoin
> dev are going to have different value sets. I think this is OK, to a
> degree. But where a lot of communication breakdown occurs is when people
> are debating the properties of #2/#3 when they don't even know that there
> is disagreement between them on #1. I think that everyone having an
> individual answer to #1 can make these discussions go a lot more smoothly
> in the technical sphere since I think most people can suspend their own
> values for the sake of analyzing the effectiveness of a particular
> approach. I am concerned, however, that if value differences are allowed to
> be passed off as technical evaluations, the quality of the conversation may
> erode to the point where no meaningful advancement can happen anymore,
> since we will lose our shared framework for understanding. If this occurs
> too soon, I believe quite strongly that Bitcoin will be captured through
> the increasing power of custodial institutions.
>
> Keagan
>
> On Wed, Apr 27, 2022 at 11:22 AM <micaroni@gmail.com> wrote:
>
>> The idea seems interesting at first glance, but soon we see several
>> problems. The biggest problem with votes of this type is that they can be
>> easily manipulated. Imagine a powerful attacker who impersonates someone in
>> good faith and arrives with a proposal that looks great but has dark ends
>> behind it (and that no one has simply noticed yet). It would be enough for
>> this attacker to convince major wallets, major exchanges and even
>> individuals to believe him. It could be with a good marketing campaign or
>> even buying these people. This would create a "false consensus", a
>> misconception of what consensus means.
>>
>> For me, the consensus should follow the current line: discussions and
>> tests carried out by experts. We all know that the most important devs have
>> the most weight in discussions. And that's how it should be, because they
>> understand far better than any other lowly mortal. Consensus simply means
>> that there are not at least two or three important people opposing the idea
>> with solid arguments. Is it very subjective and difficult? Yes. For sure.
>> We all yearn for objective answers or methods. However, any method would
>> fail. At the end, after numerous discussions and an apparent consensus, the
>> objective answer and the real consensus will be obtained in the network, in
>> the nodes upgrading. If there is a big war, the network will end up
>> splitting in two, as it has in the past. To avoid any unwanted splits we
>> discuss for exhaustion here in the list.
>>
>> I don't think flagging transactions would be a good method to measure
>> this sort of thing. You are handing important technical discussions into
>> the hands of those who have no idea about the subject.
>>
>> Felipe.
>>
>> On Tue, Apr 26, 2022 at 5: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
>>>
>>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">Hi Keagan,<br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The
 worst case scenario is: no new proposals are accepted and the Bitcoin=20
remains the same. This is not so bad. I think a bad actor will usually=20
want to *add* (or remove) something that breaks. I don&#39;t know if the bo=
ycott of new=20
proposals is as effective in breaking Bitcoin. It means the more=20
important devs are not in full control, but they have the (kind of) power o=
f veto if=20
they have really rational arguments. The most harm they can do is delay thi=
ngs a little.</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">But
 remember: after all, everyone is free to fork the code, try to=20
change something and perhaps create undesirable splits in the network.</div=
></div></div><div><br></div><div><br></div><div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default">Felipe.</div><br></div><div><br></div><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27, 2022 at 3:32 PM Keagan=
 McClelland &lt;<a href=3D"mailto:keagan.mcclelland@gmail.com">keagan.mccle=
lland@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>Felipe,</div><div><br></div>&gt;=C2=A0=
<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">For=
 me, the consensus should follow the current line: discussions and tests ca=
rried out by experts. We all know that the most important devs have the mos=
t weight in discussions. And that&#39;s how it should be, because they unde=
rstand far better than any other lowly mortal. Consensus simply means that =
there are not at least two or three important people opposing the idea with=
 solid arguments. Is it very subjective and difficult? Yes. For sure. We al=
l yearn for objective answers or methods. However, any method would fail. A=
t the end, after numerous discussions and an apparent consensus, the object=
ive answer and the real consensus will be obtained in the network, in the n=
odes upgrading. If there is a big war, the network will end up splitting in=
 two, as it has in the past. To avoid any unwanted splits we discuss for ex=
haustion here in the list.</span><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D"col=
or:rgb(0,0,0);font-family:arial,helvetica,sans-serif">This is essentially a=
n admission that devs have control over the protocol. Users &quot;having co=
ntrol&quot; but deferring their judgement to devs is not meaningfully diffe=
rent than devs &quot;having control&quot;. Many people have asserted, quite=
 strongly, that this ought not be how Bitcoin governs itself. I myself am o=
n the fence about what is practically possible or not. However, let&#39;s s=
ay that your supposition is correct. How would we protect against a corolla=
ry scenario where a dev has a proposal that looks great but has dark ends t=
hat no one notices yet, if the process for evaluation more or less is to de=
fer to &quot;the most important devs&quot; expertise? Presumably we hash th=
is out in forums like this, but in order to &quot;override&quot; the &quot;=
most important devs&quot; we have to have a way (formalized or not) of deci=
ding when the &quot;lesser experts&quot; in aggregate have better judgement=
.</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif">Erik,</span></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><di=
v><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">&=
gt;=C2=A0</span>There are many challenges with on-chain voting, here are a =
few:</div><br><div>This may be hair-splitting but I feel it important to cl=
arify that my proposal isn&#39;t voting per se. Calling it that doesn&#39;t=
 bug me, but the mechanics are meaningfully different than a simple tally v=
ote which is the intuition that I think that term conveys. As Billy mention=
s this proposal actually requires that miners block signals from inclusion =
in the block if they themselves do not signal. I&#39;m not necessarily clai=
ming this is a superior design overall, however the &quot;flaw&quot; you po=
int out is by design in this case. My goal in the proposal was really to gi=
ve users a means of applying direct economic pressure to miners, who do ine=
vitably play a role in BIP8/BIP9 activation procedure.</div><div><br></div>=
<div>Ryan,</div><div><br></div><div>&gt; - you&#39;re feeding the Chainalys=
is beasts, when hodlers move their UTXOs;</div><div><br></div><div>Definite=
ly a frightening proposition I hadn&#39;t considered. It does open up the p=
ossibility of tracking individual preferences and targeting of political op=
ponents.</div><div><br></div><div>&gt;=C2=A0=C2=A0 - yuk, it&#39;s voting.<=
/div><div><br></div><div>I don&#39;t think the process of collecting inform=
ation on user preference is in and of itself bad. Where I think Bitcoiners =
really want to avoid voting is this notion that 51% of the constituency=C2=
=A0can bully the other 49% into whatever they want. No part of my proposal =
suggests this, nor is it something I would want.</div><div><br>-----</div><=
div><br></div><div>I think there are a few questions surrounding the issue =
of soft fork activation. Perhaps it warrants zooming out beyond even what m=
y proposal aims to solve. In my mind the most important questions surroundi=
ng this process are:<br><br>1. In an ideal world, assuming we could, with p=
erfect certainty, know anything we wanted about the preferences of the user=
 base, what would be the threshold for saying &quot;this consensus change i=
s ready for activation&quot;?</div><div>=C2=A0 =C2=A0 1a. Does that thresho=
ld change based on the nature of the consensus change (new script type/opco=
de vs. block size reduction vs. blacklisting UTXOs)?<br>=C2=A0 =C2=A0 1b. D=
o different constituencies (end users, wallets, exchanges, coinjoin coordin=
ators, layer2 protocols, miners) have a desired minimum or maximum represen=
tation in this &quot;threshold&quot;?</div><div>2. Given an answer from #1,=
 what tests can we devise to measure those levels of support directly? If w=
e can&#39;t measure it directly, can we measure different indicators that w=
ould help us infer or solve for the knowledge we want?<br>3. Can any of the=
 answers to #2 be &quot;gamed&quot;? I&#39;m defining &quot;game&quot; here=
 to mean that the measurement taken, diverges from the ground truth we are =
trying to get at in such a way that its divergence would be undetectable.</=
div><div><br></div><div>If we do not answer these sorts of questions we can=
 get technical consensus through this messy process, but when it comes to a=
ssessing user consensus, it is just going to devolve into dogma and demagog=
uery as we each have our own perceptions or agendas and there is no rigorou=
s way for anyone to refute our claims. This would, again, be an admission t=
hat devs ultimately do make protocol decisions. Perhaps it&#39;s unavoidabl=
e and we are doomed to this painful process of arguing with one another unt=
il there&#39;s=C2=A0only one opinion left standing (either because of merit=
 or just plain old grit). However, if this is the case, I don&#39;t think w=
e can honestly claim that devs don&#39;t control the protocol (as a group).=
</div><div><br></div><div>I don&#39;t think we will have broad agreement on=
 #1 as it is ultimately a value judgement and even the most intellectually =
honest people in Bitcoin dev are going to have different value sets. I thin=
k this is OK, to a degree. But where a lot of communication breakdown occur=
s is when people are debating the properties of #2/#3 when they don&#39;t e=
ven know that there is disagreement between them on #1. I think that everyo=
ne having an individual answer to #1 can make these discussions go a lot mo=
re smoothly in the technical sphere since I think most people can suspend t=
heir own values for the sake of analyzing the effectiveness of a particular=
 approach. I am concerned, however, that if value differences are allowed t=
o be passed off as technical evaluations, the quality of the conversation m=
ay erode to the point where no meaningful advancement can happen anymore, s=
ince we will lose our shared framework for understanding. If this occurs to=
o soon, I believe quite strongly that Bitcoin will be captured through the =
increasing power of custodial institutions.</div><div><br></div><div>Keagan=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Wed, Apr 27, 2022 at 11:22 AM &lt;<a href=3D"mailto:micaroni@gmail=
.com" target=3D"_blank">micaroni@gmail.com</a>&gt; wrote:<br></div><blockqu=
ote 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"><div dir=3D"ltr"=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><span lang=3D"en"><span><span>The idea seems interesting at fi=
rst glance, but soon we see several problems. The biggest problem with vote=
s of this type is that they can be easily manipulated. Imagine a powerful a=
ttacker who impersonates someone in good faith and arrives with a proposal =
that looks great but has dark ends behind it (and that no one has simply no=
ticed yet). It would be enough for this attacker to convince major wallets,=
 major exchanges and even individuals to believe him. It could be with a go=
od marketing campaign or even buying these people. This would create a &quo=
t;false consensus&quot;, a misconception of what consensus means. <br></spa=
n></span></span></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)"><span lang=3D"en"><span><span><br></span>=
</span></span></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><span lang=3D"en"><span><span>For me, the c=
onsensus should follow the current line: discussions and tests carried out =
by experts. We all know that the most important devs have the most weight i=
n discussions. And that&#39;s how it should be, because they understand far=
 better than any other lowly mortal. Consensus simply means that there are =
not at least two or three important people opposing the idea with solid arg=
uments. Is it very subjective and difficult? Yes. For sure. We all yearn fo=
r objective answers or methods. However, any method would fail. At the end,=
 after numerous discussions and an apparent consensus, the objective answer=
 and the real consensus will be obtained in the network, in the nodes upgra=
ding. If there is a big war, the network will end up splitting in two, as i=
t has in the past. To avoid any unwanted splits we discuss for exhaustion h=
ere in the list.</span></span></span></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span lang=3D"en"><s=
pan><span><br></span></span></span></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span lang=3D"en"><spa=
n><span>I don&#39;t think flagging transactions would be a good method to m=
easure this sort of thing. You are handing important technical discussions =
into the hands of those who have no idea about the subject.</span></span></=
span></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><span lang=3D"en"><span><span><br></span></span></sp=
an></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><span lang=3D"en"><span><span>Felipe.<br></span></span=
></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, Apr 26, 2022 at 5:12 PM Keagan McClelland via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi all,<d=
iv><br></div><div>Alongside the debate with CTV right now there&#39;s a sec=
ond debate that was not fully hashed out in the activation of Taproot. Ther=
e 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 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 devolves into peo=
ple claiming that their circles support/reject a proposal, AND that their c=
ircles are more broadly representative of the set of Bitcoin users as a who=
le.</div><div><br></div><div>It seems everyone in this forum has at one poi=
nt or another said &quot;I would support activation of ____ if there was co=
nsensus on it, but there isn&#39;t&quot;. This statement, in order to be tr=
ue, requires that there exist a set of conditions that would convince you t=
hat there is consensus. People have tried to dodge 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&quot; answer than any of you=
rs.</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 a=
ny influence over what rulesets get activated or don&#39;t. As such &quot;m=
iner 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;1=
7=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 si=
gnal we have to work with is miner signaling, which I think is rightly frus=
trating 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 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 t=
hat are under consideration involve miner signaling in one form or another.=
 What if we could make it such that users could more directly pressure mine=
rs 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.</div><div><br></div><div>Currently, the only means users have of=
 influencing miner decisions are A. rejection of blocks that don&#39;t foll=
ow 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 th=
e version field of a transaction that are presently ignored. If we could de=
vise a mapping between some of those free bits, and the signaling bits in t=
he 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 th=
at does not signal in the affirmative<br>- A transaction that is NOT signal=
ing MAY be included in a block regardless of that block&#39;s signaling vec=
tor</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 t=
ransaction without signaling, the user&#39;s fee becomes active=C2=A0econom=
ic 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 St=
ake, 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 =
resistant:</div><div><br></div><div>- Hashpower</div><div>- Proof of person=
hood (KYC)<br>- Capital burn/risk</div><div><br></div><div>Letting hashpowe=
r decide this is the thing that is currently contentious, KYC is dead on ar=
rival both on technical and social grounds, which really just leaves some m=
eans of getting capital into the process of consensus measurement. This mec=
hanism I&#39;m proposing is measurable completely en-protocol and doesn&#39=
;t require trust in institutions that fork futures would. Additionally it c=
ould be an auxiliary=C2=A0feature of the soft fork deployment scheme chosen=
 making it something you could neatly package all together with the deploym=
ent 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 si=
gnaling (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 =
transaction.</div><div><br></div><div>Some anticipated objections:</div><di=
v><br></div><div>1. signaling isn&#39;t voting, no deployment should be mad=
e without consensus first.</div><div>- yeah well we can&#39;t currently mea=
sure consensus right now, so that&#39;s not a super helpful thing to say an=
d is breeding ground for abuse in the form of certain people making the uns=
ubstantiated claim that consensus does or does not exist for a particular i=
nitiative</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.</di=
v><div>- I agree that wealth should not be able to strong-arm decision maki=
ng. But the status quo seems even worse where we let publicly influential p=
eople 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, cre=
ating really bad long-term balances of power.</div><div><br></div><div>3. E=
nforcing 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 h=
ow 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 operato=
rs and L2 protocol implementations power over deciding consensus.</div><div=
>- I see this as an improvement over the status quo</div><div><br></div><di=
v>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 like t=
o 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></div>
</blockquote></div>
</blockquote></div></div>

--0000000000001d6e4505ddb260c6--