summaryrefslogtreecommitdiff
path: root/db/15a16f69b5ea5988d73f89d3678681230ec57f
blob: 47be26a43a6c4a90b4a9cd687964dcbb1704506f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
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--