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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AD33F94F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 18:01:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com
[209.85.220.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 00F2924F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 18:01:53 +0000 (UTC)
Received: by mail-qk0-f173.google.com with SMTP id f133so531209qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 11:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=9cDE2yRdeXOLJgZT3K0kDP2yaOiC3Z8kbCoIBV5+65Y=;
b=TbY7iVx3LCGKv9PP+Z53TLRsuwQkSYswuSNz7gkUIde2kkeLdd3Q+8pt2SIRCjoazM
4id4b0nOLVRfEYGNLWZnruloaJ/5jN7srefazoI29HMn44CsppXt+pjZZSM60p8Yw7ky
NOgiRpgt72sIKoHLi6Yh0498cdQWN/4ihutR+fAUDVWIwsU18HVLkOfZf+jO9O5ZiT14
0dN3nr5iNXMJR1E7xPKjL9aloXycdos9d+bj42I6iI3W9T5LHAjKQ1NBoynG/Sgs4E3G
4WUYTHSd+G6dVYn+sYQmlLIBzUlLeCsKNHJovc/242zH4X0O3lzPD7WQDT03eYwbX6Gs
Ewuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=9cDE2yRdeXOLJgZT3K0kDP2yaOiC3Z8kbCoIBV5+65Y=;
b=P9yqb+8w3wD+sHI9UHCcIGVZEyL1kZxXnRWcmJjwXoFYlotJDAbcckAlwpQjhTyco5
O6kLaa69J1iCIJobhSFVJyrtPiCA6WV1iVeEIlAMLoAzntj7i+7tKDCpgQx2Jat71vBg
f/p3s2xmb95shQyYVmuRks4tYXB+bRaRAVBZPtIri2V4S2n63x49Gy/SbuqKa1zFISzZ
/70MAuYWIdwyutfzuYx7Akcabm8V9bpHDfpoB4HB7Z3sqmHbbZWn2+o7QqRIo1yYPOf/
X3wDKw2HY/loRLE5tB2z/ck5h2aZ6Us3EbeM4/r7ecxcEvdnMroFuzhpFV6z+r4/srl4
chug==
X-Gm-Message-State: AN3rC/5UXsWb2as44ufzRTj60QppkMoMxbfi3DkqmzvL7eVt3OYLxF2B
KQvS4/h//hEDIzAJ5OKIKeEbXmF++ZJk
X-Received: by 10.55.168.198 with SMTP id r189mr16410814qke.228.1492538513091;
Tue, 18 Apr 2017 11:01:53 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.0.146 with HTTP; Tue, 18 Apr 2017 11:01:52 -0700 (PDT)
In-Reply-To: <CAAUq487rDVQ9P=tr6EK+O0cT4ZBkKBhbBk1TBxdWbbQ78aZcwA@mail.gmail.com>
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>
<CAAUq487rDVQ9P=tr6EK+O0cT4ZBkKBhbBk1TBxdWbbQ78aZcwA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 18 Apr 2017 14:01:52 -0400
X-Google-Sender-Auth: uTPCgT9qsP0usozdDKHamhEpduM
Message-ID: <CAJowKgJi1HcMQMFXq_KeOgR+=tJCzZ4PJj-5QR8B_X-momD2Pg@mail.gmail.com>
To: Marcel Jamin <marcel@jamin.net>
Content-Type: multipart/alternative; boundary=001a114fe8f6e2f3f2054d74b39b
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 18 Apr 2017 18:02:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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:01:54 -0000
--001a114fe8f6e2f3f2054d74b39b
Content-Type: text/plain; charset=UTF-8
Just to be clear, the tagging would occur on the addresses, and the
weighting would be by value, so it's a measure of economic significance.
Major exchanges will regularly tag massive amounts of Bitcoins with their
capabilities.
Just adding a nice bit-field and a tagging standard, and then charting it
might be enough to "think about how to use it later". The only problem
would be that this would interfere with "other uses of op_return" ...
colored coins, etc.
Personally, I think that's OK, since the purpose is to tag economically
meaningful nodes to the Bitcoin ecosystem and colored coins, by definition,
only have value to "other ecosystems".
(Counterargument: Suppose in some future where this is used as an
alternative to BIP9 for a user-coordinated code release - especially in
situations where miners have rejected activation of a widely-regarded
proposal. Suppose also, in that future, colored coin ICO's that use
op-return are regularly used to float the shares of major corporation. It
might be irresponsible to exclude them from coordinating protocol changes.)
On Tue, Apr 18, 2017 at 10:52 AM, Marcel Jamin <marcel@jamin.net> wrote:
> Probably a bad idea for various reasons, but tagging (fee paying)
> transactions with info about the capabilities of the node that created
> it might be interesting? Might be useful to gauge economic support for
> certain upgrades, especially if excluding long transaction chains,
> etc. In the very least it would be a far better indicator than simply
> counting reachable nodes.
>
> On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > If users added a signal to OP_RETURN, might it be possible to tag all
> > validated input addresses with that signal.
> >
> > Then a node can activate a new feature after the percentage of tagged
> input
> > addresses reaches a certain level within a certain period of time?
> >
> > This could be used in addition to a flag day to trigger activation of a
> > feature with some reassurance of user uptake.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
--001a114fe8f6e2f3f2054d74b39b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Just to be clear, the tagging would occur on the=
addresses, and the weighting would be by value, so it's a measure of e=
conomic significance.=C2=A0=C2=A0 Major exchanges will regularly tag massiv=
e amounts of Bitcoins with their capabilities.<br><br></div>Just adding a n=
ice bit-field and a tagging standard, and then charting it might be enough =
to "think about how to use it later".=C2=A0=C2=A0 The only proble=
m would be that this would interfere with "other uses of op_return&quo=
t; ... colored coins, etc.=C2=A0=C2=A0 <br><br>Personally, I think that'=
;s OK, since the purpose is to tag economically meaningful nodes to the Bit=
coin ecosystem and colored coins, by definition, only have value to "o=
ther ecosystems".<br><br></div>(Counterargument: Suppose in some futur=
e where this is used as an alternative to BIP9 for a user-coordinated code =
release - especially in situations where miners have rejected activation of=
a widely-regarded proposal.=C2=A0 Suppose also, in that future, colored co=
in ICO's that use op-return are regularly used to float the shares of m=
ajor corporation.=C2=A0 It might be irresponsible to exclude them from coor=
dinating protocol changes.)<br><br><br><div><br><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Apr 18, 2017 at 10:=
52 AM, Marcel Jamin <span dir=3D"ltr"><<a href=3D"mailto:marcel@jamin.ne=
t" target=3D"_blank">marcel@jamin.net</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><span class=3D"im HOEnZb">Probably a bad idea for variou=
s reasons, but tagging (fee paying)<br>
transactions with info about the capabilities of the node that created<br>
it might be interesting? Might be useful to gauge economic support for<br>
certain upgrades, especially if excluding long transaction chains,<br>
etc. In the very least it would be a far better indicator than simply<br>
counting reachable nodes.<br>
<br>
On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">> If users added a signal=
to OP_RETURN, might it be possible to tag all<br>
> validated input addresses with that signal.<br>
><br>
> Then a node can activate a new feature after the percentage of tagged =
input<br>
> addresses reaches a certain level within a certain period of time?<br>
><br>
> This could be used in addition to a flag day to trigger activation of =
a<br>
> feature with some reassurance of user uptake.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">> __________________=
____________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
><br>
</div></div></blockquote></div><br></div>
--001a114fe8f6e2f3f2054d74b39b--
|
