Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C6E2C002D for ; Wed, 27 Apr 2022 17:22:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 32EA160864 for ; Wed, 27 Apr 2022 17:22:47 +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 Psk1O2IeRIf1 for ; Wed, 27 Apr 2022 17:22:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by smtp3.osuosl.org (Postfix) with ESMTPS id 90EFE607D0 for ; Wed, 27 Apr 2022 17:22:45 +0000 (UTC) Received: by mail-pl1-x62c.google.com with SMTP id k4so2132017plk.7 for ; Wed, 27 Apr 2022 10:22:45 -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=4xMpY2Z+rMfXUJuPvqu7xIZ03efrZfnSEU6ith7WPao=; b=cvgifWgfsK2G7qGeLcYIP0l0Pk6Qb2Ii/ueigQvIWcxaF2GzGIBOZThtx1Zj1LC3eK 6DeXYgU8Mzl3D4gN06zDOGZjtX6G6kjNEAB6JAxw+F40Nc/Uzghuto3FlVKMzJq5vZGt Ii9/e/Ztcng/TY6o1IANHt+dFCtO3/2cMPxe9qfouCI0TURks/Cnbonoo7AgAYRFLFpU rs+bc3xMeqCVGkMyz90D86nMllzz9BiEL2PMLbZU43RfuBFZgYxtxcC1CZjesotpS4+M R2yWgoyxpYUJaVEj/ov0vlb/pW3QGO2oajtcCTLnvb+41WWOXjv9bGS4b8F2sEgn4/bl CMeg== 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=4xMpY2Z+rMfXUJuPvqu7xIZ03efrZfnSEU6ith7WPao=; b=WWUhcxxWsS6odYU8LMalju1yvDnUe8aqiMmK4SNyAfMF8MKsr7mCrvXbRI+//+HfnE fcWZHaJxFF3tbcy5stfLpVLYz+Tc5RgDRtIMz670aO/A67C3KNy9uuYdoZE7MqS8284c 4rk26qfpJZ32vT0UKL5KeAkX1DLNaJwKd162WcOWYYOpcomwihumdsBa4Xt+4aA/m8CU nK22avCrNsQU/NMz+fEhngT9D7Mbzd04BFORSbt2m/Jdn0UxXpPrSHPqpsuSpM0CpYrw NMbwugjwIenAiBt+l48tFoMDBQ9lANr80WPW7HfDdlwX5hTkX6wR0hHEvHEtSuBXnLIy pUDg== X-Gm-Message-State: AOAM532ITTwwvRVwpYJrJ4QUaY6bsDWsnSQPfXuC7rDtGnTlOLMfIEfO 2goNydPy9Sefszg+b5COx5LJjuDhJlQePRNKGJymQwdz2kBr4g== X-Google-Smtp-Source: ABdhPJzWL3y8+a9w2fx5jjmkyN54Dh8few82TQyuUzrgz2Jq0RGRHtel+gQiAeGl78Gbn6T+DyuaOpMEuB6ZQ3FLsqg= X-Received: by 2002:a17:90a:9308:b0:1cb:a048:c140 with SMTP id p8-20020a17090a930800b001cba048c140mr34489301pjo.221.1651080164783; Wed, 27 Apr 2022 10:22:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: micaroni@gmail.com Date: Wed, 27 Apr 2022 14:22:07 -0300 Message-ID: To: Keagan McClelland , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b7b92d05dda60e0d" X-Mailman-Approved-At: Wed, 27 Apr 2022 17:36:30 +0000 Subject: Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 17:22:47 -0000 --000000000000b7b92d05dda60e0d Content-Type: text/plain; charset="UTF-8" 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 > --000000000000b7b92d05dda60e0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 som= eone in good faith and arrives with a proposal that looks great but has dar= k ends behind it (and that no one has simply noticed yet). It would be enou= gh for this attacker to convince major wallets, major exchanges and even in= dividuals to believe him. It could be with a good marketing campaign or eve= n buying these people. This would create a "false consensus", a m= isconception of what consensus means.

=
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'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.

I don't think flagging transactions= would be a good method to measure this sort of thing. You are handing impo= rtant technical discussions into the hands of those who have no idea about = the subject.
<= span class=3D"gmail-VIiyi" lang=3D"en">
Felipe.

On = Tue, Apr 26, 2022 at 5:12 PM Keagan McClelland via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hi all,

Alongside the debat= e 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 Sp= eedy Trial is or isn't, what BIP8 T/F is or isn't etc. A significan= t reason for the breakdown in civility around this debate is that because w= e don't have a means of measuring user support for proposed sof-fork ch= anges, it invariably devolves into people claiming that their circles suppo= rt/reject a proposal, AND that their circles are more broadly representativ= e of the set of Bitcoin users as a whole.

It seems= everyone in this forum has at one point or another said "I would supp= ort activation of ____ if there was consensus on it, but there isn't&qu= ot;. This statement, in order to be true, requires that there exist a set o= f conditions that would convince you that there is consensus. People have t= ried to dodge this question by saying "it's obvious", but the= reality is that it fundamentally isn't. My bubble has a different &quo= t;obvious" answer than any of yours.

Secondly= , due to the trauma of the block size wars, no one wants to utter a stateme= nt that could imply that miners have any influence over what rulesets get a= ctivated or don't. As such "miner signaling" is consistently = devalued as a signal for market demand. I don't think this is reasonabl= e since following the events of '17=C2=A0=C2=A0miners are aware that th= ey have the strong incentive that they understand market demand. Neverthele= ss, as it stands right now the only signal we have to work with is miner si= gnaling, which I think is rightly frustrating to a lot of people.

So how can we measure User Support for a proposed rule chan= ge?

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 m= iner signaling in one form or another. What if we could make it such that u= sers 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 a= lignment with how people want Bitcoin to behave.

C= urrently, the only means users have of influencing miner decisions are A. r= ejection of blocks that don't follow rules and B. paying fees for trans= action inclusion. I suggest we combine these in such a way that transaction= s 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 affirmat= ive 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 regard= less of that block's signaling vector
- (Optional) A transact= ion 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 use= r'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 environ= ment, miners could have a better view into what users do want, as would the= Bitcoin network at large.

Some may take issue wit= h the idea that people can pay for the outcome they want and may try to com= pare a method like this to Proof of Stake, but there are only 3 sybil resis= tant mechanisms I am aware of, and any "real" view into what soci= al consensus looks like MUST be sybil resistant:

-= Hashpower
- Proof of personhood (KYC)
- Capital burn/risk

Letting hashpower decide this is the thing that is cu= rrently contentious, KYC is dead on arrival both on technical and social gr= ounds, which really just leaves some means of getting capital into the proc= ess of consensus measurement. This mechanism I'm proposing is measurabl= e completely en-protocol and doesn't require trust in institutions that= fork futures would. Additionally it could be an auxiliary=C2=A0feature 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 doe= s 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 n= ot be able to strong-arm decision making. But the status quo seems even wor= se where we let publicly influential people decide consensus in such a way = where not only do they not "lose ammunition" in the process of ca= mpaigning, but actually accrue it, creating really bad long-term balances o= f power.

3. Enforcing this proposal requires its o= wn soft fork.
- Yes. It does...and there's a certain cosmic i= rony 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 po= wer 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=C2=A0forum is:
- Does a scheme like this afford=C2=A0us a better view into consensus tha= n 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/mail= man/listinfo/bitcoin-dev
--000000000000b7b92d05dda60e0d--