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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 90447C6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Mar 2016 05:14:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com
[209.85.218.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B374109
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Mar 2016 05:14:16 +0000 (UTC)
Received: by mail-oi0-f48.google.com with SMTP id m82so3324165oif.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 Mar 2016 21:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc; bh=ia3hwN03ESEc/LxuAPdDqBeo745gXDh544ZhEb081vI=;
b=EMoqT/+tuPtxYOu4GXy7Avlfl9iPwC24zzVcZaWiXNcRXaBpvmIoVGuJphp+oyQqnc
DkFmtF/Bngk3gk+En7Vo1Ze9pDIsiPkdwuifTgSvKDAf+vcBmP1BRhJZqJTPjVB14KmT
qCE2No9pg3+yKn3lpoI70r16410vm2SztvJJ6NGyG6aysCttHAnAh5kH8jU0cfpt468W
wiL+iTgNrXGXVCUqEtuGAAmJOMfoWSH0Ets1gQPM6ELiBZtXZB+G2XLG63VL8SA6IZYg
0luiBoFtPNlJnS0yc4328bas1gXHEXFnuQiPu4toZ8xc8Ts01UTUxqVlyyp5zreZEhac
hiXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=ia3hwN03ESEc/LxuAPdDqBeo745gXDh544ZhEb081vI=;
b=kNJNL0h/nfoyquOvSgyWSsN8/J7BT9nz39MiTSaA6zlRjq/bMusM+Pounluj2DsRr7
80cI9H928XHv88nSrsj5A6p6zzSUVwVA2MqwXhJ+tEzrlvsV3ypRxYNJq9YrommolP/V
UbR8wtdF1JGkne8P4uo1AzmVlF2taIvIrJegSU3P781rqKqJcITI1aMQixudEFMmeT5z
WPeV/26xQomQQjqFVwBklnFplCyS6vLXhWHjx513t8rlIgj5Uk26VpL+yYejPZLGtPqO
7pKbuxzd5oXC6PiCMikttTDg3kQBdBgEKY53XkMxTXx2IxOqpePj71Xj0JbECQdwIpCq
J9ig==
X-Gm-Message-State: AD7BkJJ50vcb2Fq+d6cczWG5Prs6jTJEgVEyTA3soBXGwzlHoftAcbE6HvjjfdC8wzqtjrGtM8KyLpD+NFct7Q==
MIME-Version: 1.0
X-Received: by 10.202.221.87 with SMTP id u84mr7270688oig.93.1457414055942;
Mon, 07 Mar 2016 21:14:15 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.55.71 with HTTP; Mon, 7 Mar 2016 21:14:15 -0800 (PST)
In-Reply-To: <CAAS2fgQi1X4v9WxT1pnd_XSyE2b8hUZUv0z5A8cOEvw5RztOKw@mail.gmail.com>
References: <CAHUwRvuR9qtYc+rVh1yPbQoESxm4m0r6a+Fd6VF=FuT0vom_HQ@mail.gmail.com>
<CAAS2fgQi1X4v9WxT1pnd_XSyE2b8hUZUv0z5A8cOEvw5RztOKw@mail.gmail.com>
Date: Mon, 7 Mar 2016 21:14:15 -0800
X-Google-Sender-Auth: fUlCV_0I-bUQFS7UG9_98x5R_Sw
Message-ID: <CAGLBAheY-LWy1YjOZz9+-M3O0jO5H3iyogdXzBaXrnj6KGjY8A@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a113d526c18618d052d82a7dd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
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, 08 Mar 2016 06:59:09 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Services bit for xthin blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 08 Mar 2016 05:14:17 -0000
X-List-Received-Date: Tue, 08 Mar 2016 05:14:17 -0000
--001a113d526c18618d052d82a7dd
Content-Type: text/plain; charset=UTF-8
I think a BIP is a good idea, but rather than making such a specific
proposal as "Let's use bit 4 to indicate communication of thin blocks," how
about a more general one like "Let's use bit(s?) 4(-5?) as user-agent
specific service bits so that if you customize your user-agent string, you
can use them for whatever you want"? That way, other clients can choose to
follow suit by saying so, or simply recognize the meaning (or lack thereof)
of those bits based on the user-agent setting. This relieves future
development from the burden of agreeing on where to put what, and allows
time and utility to show when such a user-agent-specific service bit should
be moved into the protocol section of service bits.
PS I am not well versed in the creation of standards, but the reservation
of digital real estate for self-identified customization (bits, bytes, or
whatever that will never be used by the standard) such as what I'm
proposing seems like something that probably has a standard name. "Public
provisioning" or something like that?
On Mon, Mar 7, 2016 at 12:51 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The Bitcoin Unlimited client needs a services bit to indicate that the
> node
> > is capable of communicating thin blocks. We propose to use bit 4 as
> AFAIK
> > bit 3 is already earmarked for Segregated Witness.
>
> Does this functionality change peer selection? If not, the preferred
> signaling mechanism is probably the one in BIP 130.
>
> Otherwise, I think the standard method for getting numbers has been to
> write a BIP documenting the usage. I don't know if that is intentional
> or just how things have previously happened; and I don't have much of
> an opinion on it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--001a113d526c18618d052d82a7dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I think a BIP is a good idea, but rather than making =
such a specific=20
proposal as "Let's use bit 4 to indicate communication of thin blo=
cks,"=20
how about a more general one like "Let's use bit(s?) 4(-5?) as use=
r-agent specific service bits so that if you customize your user-agent stri=
ng, you can use them for whatever you want"? That way, other clients c=
an choose to follow suit by saying so, or simply recognize the meaning (or =
lack thereof) of those bits based on the user-agent setting.=C2=A0 This rel=
ieves future development from the burden of agreeing on where to put what, =
and allows time and utility to show when such a user-agent-specific service=
bit should be moved into the protocol section of service bits.<br><br></di=
v><div>PS I am not well versed in the creation of standards, but the reserv=
ation of digital real estate for self-identified customization (bits, bytes=
, or whatever that will never be used by the standard) such as what I'm=
proposing seems like something that probably has a standard name.=C2=A0 &q=
uot;Public provisioning" or something like that?<br></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Mar 7, 2016 at =
12:51 PM, Gregory Maxwell via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"">On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone vi=
a bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> The Bitcoin Unlimited client needs a services bit to indicate that the=
node<br>
> is capable of communicating thin blocks.=C2=A0 We propose to use bit 4=
as AFAIK<br>
> bit 3 is already earmarked for Segregated Witness.<br>
<br>
</span>Does this functionality change peer selection?=C2=A0 If not, the pre=
ferred<br>
signaling mechanism is probably the one in BIP 130.<br>
<br>
Otherwise, I think the standard method for getting numbers has been to<br>
write a BIP documenting the usage. I don't know if that is intentional<=
br>
or just how things have previously happened; and I don't have much of<b=
r>
an opinion on it.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr">I like to provide some work at no charge to prove =
my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.litmo=
cracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.memer=
acing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm the we=
bmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">The V=
oluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=3D"ht=
tp://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>.<br>&=
quot;He ought to find it more profitable to play by the rules" - Satos=
hi Nakamoto</div></div>
</div>
--001a113d526c18618d052d82a7dd--
|
