From: Peter Todd <pete@petertodd•org>
To: Martin Sustrik <sustrik@250bpm•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
Date: Wed, 23 Oct 2013 15:40:39 -0400 [thread overview]
Message-ID: <20131023194039.GB31497@petertodd.org> (raw)
In-Reply-To: <52677CF7.9070609@250bpm.com>
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
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.
>
> I would love to do so.
>
> However, from what Peter Todd said above, my feeling was that spec is
> deliberately vague to force compatibility with the reference
> implementation rather than with a document.
>
> While that kind of compatibility-via-obscurity won't probably work in a
> long run, in short run it can prevent proliferation of implementations
> and thus give protocol more space and flexibility to evolve (I've done
> 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....
--
'peter'[:-1]@petertodd.org
0000000000000007362b283ac07839aba795dbfb3c5c4e831d80df9cf3bea2d5
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-10-23 19:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 14:30 Jeff Garzik
2013-10-21 14:34 ` Jeff Garzik
2013-10-21 15:46 ` Andreas Schildbach
2013-10-21 16:14 ` Jeff Garzik
2013-10-21 17:17 ` Jeff Garzik
2013-10-21 19:38 ` Jean-Paul Kogelman
2013-10-21 19:47 ` Luke-Jr
2013-10-21 20:57 ` Benjamin Cordes
2013-10-21 20:59 ` Benjamin Cordes
2013-10-22 6:39 ` Martin Sustrik
2013-10-22 6:59 ` Jean-Paul Kogelman
2013-10-22 7:03 ` Gregory Maxwell
2013-10-22 7:34 ` Martin Sustrik
2013-10-22 7:49 ` Peter Todd
2013-10-22 7:56 ` Gregory Maxwell
2013-10-22 8:20 ` Martin Sustrik
2013-10-22 14:08 ` Jeff Garzik
2013-10-23 7:38 ` Martin Sustrik
2013-10-23 19:40 ` Peter Todd [this message]
2013-10-23 20:05 ` Martin Sustrik
2013-10-23 20:27 ` Peter Todd
2013-10-23 21:07 ` Pieter Wuille
2013-10-23 21:42 ` Allen Piscitello
2013-10-23 21:49 ` Luke-Jr
2013-10-24 7:03 ` Martin Sustrik
2013-10-24 10:39 ` Jeff Garzik
2013-10-24 11:11 ` Christian Decker
2013-10-24 19:43 ` Jeremy Spilman
2013-11-19 16:32 ` Wladimir
2013-11-19 16:53 ` Drak
2013-11-19 17:01 ` Gregory Maxwell
2013-11-19 17:07 ` Drak
2013-11-19 17:45 ` Wladimir
2013-11-19 17:54 ` Gregory Maxwell
2013-11-19 17:06 ` Peter Todd
[not found] ` <CA+s+GJA=p+yvoJqUAMQQRcfYK1B8eMVSJDWaXW8o+X5dzCXkdA@mail.gmail.com>
2013-11-19 17:21 ` [Bitcoin-development] Fwd: " Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131023194039.GB31497@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=sustrik@250bpm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox