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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 51F9DB13
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 21:11:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
[209.85.213.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56AB510C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 21:11:37 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id k1so72029310vkb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 09 Mar 2016 13:11:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc;
bh=mRr9LT9A2cOlS1JLKpPFXEMQN6nK5/5NRHJY7m0FwxE=;
b=ebewhHD2r3LB9dEhKPNQH0fU+qI8TVkJy5cF0v/pZ40uz3wXrokB0g37JRxGXJV4KG
h1vuhikY8RELAO0atqMSfp9q6bhG2XUjPCd/4IRP2hQzuGdq7RT+UD5bc1sdZPNb1zx7
eClJcxMy0yFwACPVA1cpMc7ZZ+ALWtOhAY4iQMgs2L0ezm4gxjxEG+VVTEM6rw1SI0yc
VQyMk1QHUMKe7ou1TBPUncgZHY2iDpWrwhr/239V2DBb05IE+pUjX8LkHzql4jLRSh9H
/UNZGHKEC9DZneQiBwbRHEyVHc6rlPHXEdgQFOKLKtiHHrRLEQgOU2dXCbsm4gRK4k9+
1WkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:cc;
bh=mRr9LT9A2cOlS1JLKpPFXEMQN6nK5/5NRHJY7m0FwxE=;
b=DcdC4ypayq6Fe2ceuEWNtvs/upsWx9MwNesjgX7shV39mX7pin0fCpfOyu/mjH6fPO
pOB60TC8WBYQ1Z7vgHyFbKRLTGc8PGrUkEjUxVrv7limQ9TbdZ0Yx06HOsgMIfceWK9Y
22mOsp6itL47Sbmntof6z8aRpOW6ZJoMkmK3vLCR02B+jKQ4UTZUJ2SDGvVBrpUYP/+/
pghCLj0uWyNeZacDMjCW6Rc8q8FqqX8f+Q44UUhVxTwl6IRHRq+tTshXO0qmlCXc0JOR
ty9nPlaEWzrDE9kJFiHM7l0qNJy31ltHbEL2swOUlZcnEa3tsRygfTlxNxUCZ/m6qXCq
KGEw==
X-Gm-Message-State: AD7BkJIFjivdCzrwVgzrMk84TCV0cKDwvTQiRGR3QTxV9g/YsJFxsgP399G1E8+V58eWHmmUtmZ2CKOgOmLm+A==
MIME-Version: 1.0
X-Received: by 10.31.150.215 with SMTP id y206mr370245vkd.63.1457557896468;
Wed, 09 Mar 2016 13:11:36 -0800 (PST)
Received: by 10.176.2.52 with HTTP; Wed, 9 Mar 2016 13:11:36 -0800 (PST)
In-Reply-To: <CAHUwRvszz2XQ1DdfKYqrkQkxvPzkPSc=2R+LNDkDuvjyZ+U8FA@mail.gmail.com>
References: <CAHUwRvuR9qtYc+rVh1yPbQoESxm4m0r6a+Fd6VF=FuT0vom_HQ@mail.gmail.com>
<CALcNmJwY=pQuRpnb-MJ1QiME3mPUSe2KmHD7XykhX08yku9mhQ@mail.gmail.com>
<CAHUwRvv_UMoRhcwy7u2XLz19q3aKNfHXyTNbfaSUsEapFnH2kg@mail.gmail.com>
<201603081719.20662.luke@dashjr.org>
<CAHUwRvszz2XQ1DdfKYqrkQkxvPzkPSc=2R+LNDkDuvjyZ+U8FA@mail.gmail.com>
Date: Wed, 9 Mar 2016 21:11:36 +0000
Message-ID: <CAE-z3OWMz0qHKDNFLGYEpd=c9j9aA7hU15VZn=LevWHgbEtnqA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140fdd8a8c2a3052da42474
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW 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: Wed, 09 Mar 2016 23:39:59 +0000
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: Wed, 09 Mar 2016 21:11:41 -0000
--001a1140fdd8a8c2a3052da42474
Content-Type: text/plain; charset=UTF-8
On Wed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thanks for your offer Luke, but we are happy with our own process and,
> regardless of historical provenance, see this mailing list and the BIP
> process as very Core specific for reasons that are too numerous to describe
> here but should be obvious to anyone who has been aware of the last year of
> Bitcoin history.
>
One of the advantages with the BIP process is that it means that there are
hashlocked descriptions of the specs available for people to implement
against.
The BIP process is not the same as getting a PR accepted into core. It is
not a veto based process. If you write the BIP and it doesn't have any
serious technical problems, then it will be accepted into the BIP repo.
Getting it marked as "final" is harder but I don't think that matters
much. I don't think that core would actually use a service bit that was
claimed in a BIP, even if the BIP wasn't final. Maybe in 20 years if thin
blocks aren't being used, they might recycle it. It would be pretty
obviously an aggressive act otherwise.
The NODE_GETUTXO bit is a perfect example of that. They don't think it is
a good idea, but they still accepted the claim on the bit, because there
are nodes actually using it.
On the other hand, the BIP git repository is hosted on the /bitcoin github
site, so in that context it can be seen as linked with core. I wouldn't be
surprised if that specific objection was raised when it was moved from the
wiki to github. Luke may be willing to change that if you think that would
be worth changing?
With regards to the proposal, the description on the forum link isn't
sufficient for an alternative client to implement it. I had a look at the
thread and I think that this is the implementation?
https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b
Is the intention here to simply reserve the bit for thin blocks usage or to
define the specification for inter-operation with other clients?
Perhaps there could be a process for claiming service bits as it can be
useful to claim a bit in advance of actually finalizing the feature.
- Claim bit with a reasonable justification (good faith intent to implement
and the bit is useful for the feature)
- Within 3 months have a finalized description of the feature that lets
other clients implement it
- Within 6 months have working software that deploys the feature
- After 6 months of it actually being in active use, the bit is "locked"
and stays assigned to that feature
There could be an expiry process if it ends up not being used after all.
Requiring a public description of the feature seems like a reasonable
requirement in exchange for the community assigning the service bit, but we
don't want to go to far. There is no point in having lots of free bits
that end up never being used. Worst case, the addr message could be
updated to add more bits.
--001a1140fdd8a8c2a3052da42474
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev <span dir=3D"lt=
r"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Thanks f=
or your offer Luke, but we are happy with our own process and, regardless o=
f historical provenance, see this mailing list and the BIP process as very =
Core specific for reasons that are too numerous to describe here but should=
be obvious to anyone who has been aware of the last year of Bitcoin histor=
y.<span class=3D""></span><br></div></div></blockquote><div><br></div><div>=
One of the advantages with the BIP process is that it means that there are =
hashlocked descriptions of the specs available for people to implement agai=
nst.<br><br></div><div>The BIP process is not the same as getting a PR acce=
pted into core.=C2=A0 It is not a veto based process.=C2=A0 If you write th=
e BIP and it doesn't have any serious technical problems, then it will =
be accepted into the BIP repo.=C2=A0 <br><br>Getting it marked as "fin=
al" is harder but I don't think that matters much.=C2=A0 I don'=
;t think that core would actually use a service bit that was claimed in a B=
IP, even if the BIP wasn't final.=C2=A0 Maybe in 20 years if thin block=
s aren't being used, they might recycle it.=C2=A0 It would be pretty ob=
viously an aggressive act otherwise.<br><br></div><div>The NODE_GETUTXO bit=
is a perfect example of that.=C2=A0 They don't think it is a good idea=
, but they still accepted the claim on the bit, because there are nodes act=
ually using it.<br></div><div><br>On the other hand, the BIP git repository=
is hosted on the /bitcoin github site, so in that context it can be seen a=
s linked with core.=C2=A0 I wouldn't be surprised if that specific obje=
ction was raised when it was moved from the wiki to github.=C2=A0 Luke may =
be willing to change that if you think that would be worth changing?<br><br=
></div><div>With regards to the proposal, the description on the forum link=
isn't sufficient for an alternative client to implement it.=C2=A0 I ha=
d a look at the thread and I think that this is the implementation?<br><br>=
<a href=3D"https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb=
1323544173f03d45373b">https://github.com/ptschip/bitcoinxt/commit/7ea5854a3=
599851beffb1323544173f03d45373b</a><br><br></div><div></div><div>Is the int=
ention here to simply reserve the bit for thin blocks usage or to define th=
e specification for inter-operation with other clients?<br><br></div><div>P=
erhaps there could be a process for claiming service bits as it can be usef=
ul to claim a bit in advance of actually finalizing the feature.<br><br></d=
iv><div>- Claim bit with a reasonable justification (good faith intent to i=
mplement and the bit is useful for the feature)<br></div><div>- Within 3 mo=
nths have a finalized description of the feature that lets other clients im=
plement it<br></div><div>- Within 6 months have working software that deplo=
ys the feature<br></div><div>- After 6 months of it actually being in activ=
e use, the bit is "locked" and stays assigned to that feature<br>=
<br>There could be an expiry process if it ends up not being used after all=
.=C2=A0 Requiring a public description of the feature seems like a reasonab=
le requirement in exchange for the community assigning the service bit, but=
we don't want to go to far.=C2=A0 There is no point in having lots of =
free bits that end up never being used.=C2=A0 Worst case, the addr message =
could be updated to add more bits.<br></div><div></div></div></div></div>
--001a1140fdd8a8c2a3052da42474--
|
