Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Date: Wed, 23 Oct 2013 15:40:39 -0400
From: Peter Todd <pete@petertodd.org>
To: Martin Sustrik <sustrik@250bpm.com>
Message-ID: <20131023194039.GB31497@petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f"
Content-Disposition: inline
In-Reply-To: <52677CF7.9070609@250bpm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Precedence: list


--aVD9QWMuhilNxW9f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 23, 2013 at 09:38:31AM +0200, Martin Sustrik wrote:
> On 22/10/13 16:08, Jeff Garzik wrote:
> > All that is good practice, but we should avoid adding burdensome
> > process that might discourage BIP writing.
> >
> > Consider a distributed approach:  if you feel a draft needs more
> > sections or better language, submit a pull request yourself and help
> > community-edit the document.
>=20
> I would love to do so.
>=20
> However, from what Peter Todd said above, my feeling was that spec is=20
> deliberately vague to force compatibility with the reference=20
> implementation rather than with a document.
>=20
> While that kind of compatibility-via-obscurity won't probably work in a=
=20
> long run, in short run it can prevent proliferation of implementations=20
> and thus give protocol more space and flexibility to evolve (I've done=20
> the same trick with ZeroMQ myself once).

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.


I gotta get around to writing a "Developers" section for the FAQ
explaining this stuff....

--=20
'peter'[:-1]@petertodd.org
0000000000000007362b283ac07839aba795dbfb3c5c4e831d80df9cf3bea2d5

--aVD9QWMuhilNxW9f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSaCY3AAoJEBmcgzuo5/CF9Z8IAIE1J/HyTm52ePhbw3H6V7yr
5iCZ/Cy963RHfVVrBfB3LJfqwT+HFfQ1N2a6+/rm+AvztWN5gq7Mr+78OkALshc+
GpvIMTB0RGHnPmdP07JYn5oU/gHlFbaD53qMkzvItRJ0+/khhmuZfRmYmlNmbs7j
pua+h2LonurH8mxnHes/RJwESPEQDEnOTThFfgyRdZuef8buWnfCVOsc3tSn2qj/
ekCEZJesTZlyMY1Vx9zPGuFfcBy90mdJyyihB71RRBcCcR9K9+2bt6uM1trO5O7V
Moa9PCdw8pjfQpwWX/tmvMpom53a2h5ouDVG55WF9UoME4iqPhKZKWCB1mib23I=
=VjKm
-----END PGP SIGNATURE-----

--aVD9QWMuhilNxW9f--