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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allen.piscitello@gmail.com>) id 1VZ6C8-0006Ye-Qa
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Oct 2013 21:42:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.45 as permitted sender)
client-ip=74.125.82.45; envelope-from=allen.piscitello@gmail.com;
helo=mail-wg0-f45.google.com;
Received: from mail-wg0-f45.google.com ([74.125.82.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZ6C4-0001lq-Gs
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Oct 2013 21:42:24 +0000
Received: by mail-wg0-f45.google.com with SMTP id z12so1478004wgg.12
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Oct 2013 14:42:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.90.70 with SMTP id bu6mr3223664wib.45.1382564534264;
Wed, 23 Oct 2013 14:42:14 -0700 (PDT)
Received: by 10.194.85.112 with HTTP; Wed, 23 Oct 2013 14:42:14 -0700 (PDT)
In-Reply-To: <CAPg+sBjv5We415atZocrZniKexFnKmUXB+bMC-tSG4ehQK9rwQ@mail.gmail.com>
References: <791a727f-2188-4848-bd77-ea733c8c5c2c@me.com>
<201310211947.59640.luke@dashjr.org> <52661DB7.7040805@250bpm.com>
<FAE2A544-9295-4087-96DE-D4602D109CBD@me.com>
<CAAS2fgS2f=gYRSr1n2DzK7CUH3xG3J2JMnDreCKBoCcJcpGLxg@mail.gmail.com>
<52662AA1.5050509@250bpm.com>
<CAJHLa0NDus+Ou5go8b_OHvjYW8f7oxXbpxnHTG3dcvxGR49nxA@mail.gmail.com>
<52677CF7.9070609@250bpm.com>
<20131023194039.GB31497@petertodd.org> <52682C24.30700@250bpm.com>
<20131023202731.GA31783@petertodd.org>
<CAPg+sBjv5We415atZocrZniKexFnKmUXB+bMC-tSG4ehQK9rwQ@mail.gmail.com>
Date: Wed, 23 Oct 2013 16:42:14 -0500
Message-ID: <CAJfRnm4wJzk885rzV7Gn_9AF10M8O=3GV06MN2oag64YpmMUJA@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=f46d043be27af1ac7404e96f6351
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(allen.piscitello[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VZ6C4-0001lq-Gs
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 21:42:25 -0000
--f46d043be27af1ac7404e96f6351
Content-Type: text/plain; charset=ISO-8859-1
I think formalizing the specification could go a long way and encouraging
alternate implementations is going to be the best way to reduce unexpected
small bugs having a bad effect except on the "buggy" node.
That being said, it's a huge chicken and egg problem. No one wants to go
off the reference client since it could lead to working on a forked chain
as a miner or having bad data as a client.
I don't know if there is a good way to try to take small pieces, get
consensus, possibly have some type of universal test cases and running on
testnet that would solve the problem.
I wouldn't mind taking on parts of this when I have time, specifically
transactions/scripting. Obviously if there are better qualified people who
are interested, have at it!
On Wed, Oct 23, 2013 at 4:07 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd <pete@petertodd.org> wrote:
> > On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote:
> >> On 23/10/13 21:40, Peter Todd wrote:
> >>
> >> >The reference implementation is the specification - the "specification"
> >> >on the wiki is best thought of as a set of Coles Notes on the real
> >> >specification. If you don't already understand that and the nuance of
> >> >that statement you should assume the protocol is fixed in stone and
> >> >doesn't evolve at all; that statement is not quite true, but it's very
> >> >close to the truth.
> >>
> >> Does that imply that the notes are deliberately obscured to force
> >> everyone to check the source code?
> >
> > What's on the wiki is mostly the work of people who aren't working on
> > the reference implementation, so no, you can't say that.
>
> Indeed, I know of few people who are familiar with the source code
> that use the wiki.
>
> I do think that is a pity. The openness and transparency of the
> protocol is essential to trusting the system (and shouldn't be limited
> to those digging through the source code), and for that reason alone I
> think it needs to be well-documented.
>
> I also do agree with earlier comments, that due to the nature of the
> consensus problem Bitcoin solves, it will always be the network that
> dictates what the actual rules are - anything else can result in
> inresolvable forks. If a "formal" specification were written, and we
> would find out that the majority of nodes on the network deviate from
> it in a subtle way, those nodes would be buggy in the sense that they
> aren't doing what was expected, but it would be the specification that
> is incorrect for not following the rules of the network. In short,
> consistency is more important than correctness, and for that reason,
> writing alternate implementation will always be hard and dangerous.
>
> However, I do not think that making it hard to find information about
> the details of the system is the way to go. Alternate implementations
> are likely inevitable, and in the long run probably a win for the
> ecosystem. If effort is put into accurately describing the rules, it
> should indeed carry a strong notice about it being descriptive rather
> than normative.
>
> If someone is willing to work on that, I am (and likely many people in
> #bitcoin-dev are) available for any questions about the protocol and
> its semantics.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d043be27af1ac7404e96f6351
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think formalizing the specification could go a long way =
and encouraging alternate implementations is going to be the best way to re=
duce unexpected small bugs having a bad effect except on the "buggy&qu=
ot; node.<div>
<br></div><div>That being said, it's a huge chicken and egg problem. =
=A0No one wants to go off the reference client since it could lead to worki=
ng on a forked chain as a miner or having bad data as a client.</div><div><=
br>
</div><div>I don't know if there is a good way to try to take small pie=
ces, get consensus, possibly have some type of universal test cases and run=
ning on testnet that would solve the problem.</div><div><br></div><div>
I wouldn't mind taking on parts of this when I have time, specifically =
transactions/scripting. =A0Obviously if there are better qualified people w=
ho are interested, have at it!</div></div><div class=3D"gmail_extra"><br><b=
r>
<div class=3D"gmail_quote">On Wed, Oct 23, 2013 at 4:07 PM, Pieter Wuille <=
span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_=
blank">pieter.wuille@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"im">On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd <<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br>
> On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote:<br>
>> On 23/10/13 21:40, Peter Todd wrote:<br>
>><br>
>> >The reference implementation is the specification - the "=
specification"<br>
>> >on the wiki is best thought of as a set of Coles Notes on the =
real<br>
>> >specification. If you don't already understand that and th=
e nuance of<br>
>> >that statement you should assume the protocol is fixed in ston=
e and<br>
>> >doesn't evolve at all; that statement is not quite true, b=
ut it's very<br>
>> >close to the truth.<br>
>><br>
>> Does that imply that the notes are deliberately obscured to force<=
br>
>> everyone to check the source code?<br>
><br>
> What's on the wiki is mostly the work of people who aren't wor=
king on<br>
> the reference implementation, so no, you can't say that.<br>
<br>
</div>Indeed, I know of few people who are familiar with the source code<br=
>
that use the wiki.<br>
<br>
I do think that is a pity. The openness and transparency of the<br>
protocol is essential to trusting the system (and shouldn't be limited<=
br>
to those digging through the source code), and for that reason alone I<br>
think it needs to be well-documented.<br>
<br>
I also do agree with earlier comments, that due to the nature of the<br>
consensus problem Bitcoin solves, it will always be the network that<br>
dictates what the actual rules are - anything else can result in<br>
inresolvable forks. If a "formal" specification were written, and=
we<br>
would find out that the majority of nodes on the network deviate from<br>
it in a subtle way, those nodes would be buggy in the sense that they<br>
aren't doing what was expected, but it would be the specification that<=
br>
is incorrect for not following the rules of the network. In short,<br>
consistency is more important than correctness, and for that reason,<br>
writing alternate implementation will always be hard and dangerous.<br>
<br>
However, I do not think that making it hard to find information about<br>
the details of the system is the way to go. Alternate implementations<br>
are likely inevitable, and in the long run probably a win for the<br>
ecosystem. If effort is put into accurately describing the rules, it<br>
should indeed carry a strong notice about it being descriptive rather<br>
than normative.<br>
<br>
If someone is willing to work on that, I am (and likely many people in<br>
#bitcoin-dev are) available for any questions about the protocol and<br>
its semantics.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
October Webinars: Code for Performance<br>
Free Intel webinars can help you accelerate application performance.<br>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr=
om<br>
the latest Intel processors and coprocessors. See abstracts and register &g=
t;<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60135991&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60135991&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--f46d043be27af1ac7404e96f6351--
|
