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; 
MIME-Version: 1.0
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
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Precedence: list

--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 &quot;buggy&qu=
ot; node.<div>
<br></div><div>That being said, it&#39;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&#39;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&#39;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">&lt;<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_=
blank">pieter.wuille@gmail.com</a>&gt;</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 &lt;<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br>
&gt; On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote:<br>
&gt;&gt; On 23/10/13 21:40, Peter Todd wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt;The reference implementation is the specification - the &quot;=
specification&quot;<br>
&gt;&gt; &gt;on the wiki is best thought of as a set of Coles Notes on the =
real<br>
&gt;&gt; &gt;specification. If you don&#39;t already understand that and th=
e nuance of<br>
&gt;&gt; &gt;that statement you should assume the protocol is fixed in ston=
e and<br>
&gt;&gt; &gt;doesn&#39;t evolve at all; that statement is not quite true, b=
ut it&#39;s very<br>
&gt;&gt; &gt;close to the truth.<br>
&gt;&gt;<br>
&gt;&gt; Does that imply that the notes are deliberately obscured to force<=
br>
&gt;&gt; everyone to check the source code?<br>
&gt;<br>
&gt; What&#39;s on the wiki is mostly the work of people who aren&#39;t wor=
king on<br>
&gt; the reference implementation, so no, you can&#39;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&#39;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 &quot;formal&quot; 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&#39;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60135991&amp;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--