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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 74697305
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 18:07:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 010981A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 18:07:37 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id r190so3798467wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 11:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=UODjKLtR1SXMW7S4f8sAIThq9bmKKCurgTvaX224+cQ=;
b=GKilcBZLjdcTSs3iOvIrAOTj9NgFesgr88nUibPpgmBqUboTao5o5h6YwYqbu+S/5i
9yC50nT//2DqcdJ7OWQQdKue66qg1PaMiIPAPV39mnuAXX4dPZhk4bxfnyGYS+NcaGhF
C4M0fTDE7i5Pm9noGlP7mlIXSSz8HWSOZIgnIJ1oVuVNRnQabPl3oqdMD7WE/f2SYMuC
5pBkIZU0RZ8OtoG+Zu4uNq0XEJQ+HRdelouOu6cxVUjSWJXEx42EngFcdOZgUKixyDvF
60U678HO9fqAEiD5nede3VP4UzZgwNkwyeuFNyyhWxRX5iWCwK4NkrCfJBhjzebrlbRi
kf2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=UODjKLtR1SXMW7S4f8sAIThq9bmKKCurgTvaX224+cQ=;
b=jnZ61plUG5hXjngESs5s576k6wWWIxZaPfqKuq6jCTOS7E4T4OLAKJfYrWN8QFYWkp
/xQIGsKfM0yntStI5YgLuXWgULeFCNVJUF9qHixYMaaHKUp1VcMYrSh+JehPG9mMOATP
ztMU0IenY4aaUEsu7mEu9xnABz2qEKxY6v/znYlm3qxHyf5rSPdnCFYSiSO9eflq8g+d
y5HaddzT6n12wqNOwy0NqOblM3od5M2XgBCC7VK5HXoxA2w9FPTA2KZucHrmGpc5HVjq
VlwflfJuN9xG3ru660rYYzMBDLDkLQGB6mnvPJs0/qz7anWTwLBHfprt6LNrB3L+KFYn
8S6Q==
X-Gm-Message-State: AN3rC/5zLpK4giyr3XeNYonq0RJyDo+L1nl37P8Qj8kPmDdYJrehGnF9
HzyoZPP3CF63ICi6Hl4+0pkB+SmjH7LL
X-Received: by 10.28.109.3 with SMTP id i3mr14546520wmc.121.1492538856593;
Tue, 18 Apr 2017 11:07:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJ38kA_vPGF6KpKEnrRzStrk-Mj87bttaOw-dvLW675Jw@mail.gmail.com>
<CAJowKgK4j=sL2vh1bxWh2WWw0vw1PuxfJ39JW7bQS-UDzKh6CQ@mail.gmail.com>
<CAJowKgKAnrMKiLdONrXJtGQYhYgRSXq7JNWrY=zUEMvw4WSX9w@mail.gmail.com>
<CAJowKgL-NB0zF-Ud52Jr6n0Fo-uV=bXzVAFMOKmhAVA0RdRVuQ@mail.gmail.com>
<CAJowKgJGZJMondTmsdOLdqqY1mf9S+TaB8UmdCtsLF6PA2RSJw@mail.gmail.com>
<CAJowKg+gZcNO+-sdmt55KOt+zuN+8m7Hiqh77s9=gYpyszDwmA@mail.gmail.com>
<CAJowKgKC4+6vv0QUH_DRASVqU4jui-iXG6TDgEpGUHRkVwJFqg@mail.gmail.com>
<CAJowKgKH2h1QwpEvZ30OuEUsTCg1OoD6JcuXdmS+d_pKpygFcQ@mail.gmail.com>
<CAJowKg+EJGXA5=LjJhCo1YevQtBubEftSNPfnzE4b5ESCwrUMg@mail.gmail.com>
<CAJowKgLQCqL37oCzkJc8gPnUCkPYtF6G8_7Ug4AP5FpTOonBWQ@mail.gmail.com>
<CAJowKgJ-eoF6ZCKrWbJQDcMK8-jTZxD+J_6tGAyfXz+HYrqmXg@mail.gmail.com>
<CAJowKgKEVxS9OCg=Lioc1gRAy1Ftc27bp3nr2R9MQX-VQ9PrhQ@mail.gmail.com>
In-Reply-To: <CAJowKgKEVxS9OCg=Lioc1gRAy1Ftc27bp3nr2R9MQX-VQ9PrhQ@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 18 Apr 2017 18:07:25 +0000
Message-ID: <CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1147dd4e5c6578054d74c84b
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Transaction signalling
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 18 Apr 2017 18:07:39 -0000
--001a1147dd4e5c6578054d74c84b
Content-Type: text/plain; charset=UTF-8
I really like the idea of extending signalling capabilities to the
end-users. It gives stakeholders a voice in the decisions we take in
the network, and are a clear signal to all other involved parties. It
reminds me of a student thesis I supervised some time ago [1], in
which we explored various signalling ideas.
I think we have a number of fields that may be used for such a
signalling, e.g., OP_RETURN, locktime, and output scripts. I think
OP_RETURN is probably not the field you'd want to use though since it
adds data that needs to be transferred, stored for bootstrap, and
outputs in the UTXO would need to be tagged with additional
information. Locktime has the advantage of being mostly a freeform
field for values in the past, but it clashes with other uses that may
rely on it. Furthermore, it is the transaction creator that specifies
the locktime, hence the signal trails one hop behind the current
owner, i.e., the actual stakeholder.
I think probably the best field to signal would be the output
script. It is specified by the recipient of the funds, i.e., the
current owner, and is already stored in the UTXO, so a single pass can
tally up the votes. We could for example use the last 4 bits of the
pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1
depending on the stakeholders desired signal). We'd need to define
similar semantics for other script types, but getting the standard
scripts to be recognized should be simple.
In the spirit of full disclosure I'd like to also mention some of the
downsides of voting this way. Unlike the OP_RETURN proposal, users
that do not intend to signal will also be included in the tally. I'd
expect the signals of these users to be random with a 50% chance of
either outcome, so they should not influence the final result, but may
muddy the water depending on what part of the population is
signalling. The opt-in should make sure that the majority of votes are
actually voluntary votes, and not just users that randomly select a
pubkey/pubkeyhash, and can be adjusted as desired, though higher
values require more grinding on behalf of the users.
The grinding may also exacerbate some problems we already have with
the HD Wallet lookahead, since we now skip a number of addresses, so
we should not require too many opt-in bits.
So there are some problems we'd need to tackle, but I'm really excited
about this, as it could provide data to make informed decisions, and
should put an end to the endless speculation about the will of the
economic majority.
Cheers,
Christian
[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf
--001a1147dd4e5c6578054d74c84b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I really like the idea of extending signalling capabi=
lities to the</div><div>end-users. It gives stakeholders a voice in the dec=
isions we take in</div><div>the network, and are a clear signal to all othe=
r involved parties. It</div><div>reminds me of a student thesis I supervise=
d some time ago [1], in</div><div>which we explored various signalling idea=
s.</div><div><br></div><div>I think we have a number of fields that may be =
used for such a</div><div>signalling, e.g., OP_RETURN, locktime, and output=
scripts. I think</div><div>OP_RETURN is probably not the field you'd w=
ant to use though since it</div><div>adds data that needs to be transferred=
, stored for bootstrap, and</div><div>outputs in the UTXO would need to be =
tagged with additional</div><div>information. Locktime has the advantage of=
being mostly a freeform</div><div>field for values in the past, but it cla=
shes with other uses that may</div><div>rely on it. Furthermore, it is the =
transaction creator that specifies</div><div>the locktime, hence the signal=
trails one hop behind the current</div><div>owner, i.e., the actual stakeh=
older.</div><div><br></div><div>I think probably the best field to signal w=
ould be the output</div><div>script. It is specified by the recipient of th=
e funds, i.e., the</div><div>current owner, and is already stored in the UT=
XO, so a single pass can</div><div>tally up the votes. We could for example=
use the last 4 bits of the</div><div>pubkey/pubkeyhash to opt in (3 leadin=
g 0 bits) and the vote (0/1</div><div>depending on the stakeholders desired=
signal). We'd need to define</div><div>similar semantics for other scr=
ipt types, but getting the standard</div><div>scripts to be recognized shou=
ld be simple.</div><div><br></div><div>In the spirit of full disclosure I&#=
39;d like to also mention some of the</div><div>downsides of voting this wa=
y. Unlike the OP_RETURN proposal, users</div><div>that do not intend to sig=
nal will also be included in the tally. I'd</div><div>expect the signal=
s of these users to be random with a 50% chance of</div><div>either outcome=
, so they should not influence the final result, but may</div><div>muddy th=
e water depending on what part of the population is</div><div>signalling. T=
he opt-in should make sure that the majority of votes are</div><div>actuall=
y voluntary votes, and not just users that randomly select a</div><div>pubk=
ey/pubkeyhash, and can be adjusted as desired, though higher</div><div>valu=
es require more grinding on behalf of the users.</div><div><br></div><div>T=
he grinding may also exacerbate some problems we already have with</div><di=
v>the HD Wallet lookahead, since we now skip a number of addresses, so</div=
><div>we should not require too many opt-in bits.</div><div><br></div><div>=
So there are some problems we'd need to tackle, but I'm really exci=
ted</div><div>about this, as it could provide data to make informed decisio=
ns, and</div><div>should put an end to the endless speculation about the wi=
ll of the</div><div>economic majority.</div><div><br></div><div>Cheers,</di=
v><div>Christian</div><div><br></div><div>[1] <a href=3D"http://pub.tik.ee.=
ethz.ch/students/2015-HS/SA-2015-30.pdf">http://pub.tik.ee.ethz.ch/students=
/2015-HS/SA-2015-30.pdf</a></div></div>
--001a1147dd4e5c6578054d74c84b--
|
