From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VZIpU-0000VF-A7 for bitcoin-development@lists.sourceforge.net; Thu, 24 Oct 2013 11:11:52 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=decker.christian@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VZIpT-0006HO-9e for bitcoin-development@lists.sourceforge.net; Thu, 24 Oct 2013 11:11:52 +0000 Received: by mail-oa0-f50.google.com with SMTP id j6so1565469oag.9 for ; Thu, 24 Oct 2013 04:11:46 -0700 (PDT) X-Received: by 10.182.40.134 with SMTP id x6mr1706795obk.31.1382613105898; Thu, 24 Oct 2013 04:11:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.126.210 with HTTP; Thu, 24 Oct 2013 04:11:05 -0700 (PDT) In-Reply-To: <5268C632.3030005@250bpm.com> References: <791a727f-2188-4848-bd77-ea733c8c5c2c@me.com> <201310211947.59640.luke@dashjr.org> <52661DB7.7040805@250bpm.com> <52662AA1.5050509@250bpm.com> <52677CF7.9070609@250bpm.com> <20131023194039.GB31497@petertodd.org> <52682C24.30700@250bpm.com> <20131023202731.GA31783@petertodd.org> <5268C632.3030005@250bpm.com> From: Christian Decker Date: Thu, 24 Oct 2013 13:11:05 +0200 Message-ID: To: Martin Sustrik Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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: 250bpm.com] -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 (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1VZIpT-0006HO-9e Cc: Bitcoin Development 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 11:11:52 -0000 I'd like to add some historical background about how the "protocol specification" came to be in the first place. A bit over three years [1] ago I started an attempt to document the network protocol, by reverse engineering it from the satoshi client. My goal, back then, was to enable like-minded engineers to create alternative clients and move away from the client-monoculture that is still predominant today. It was clear from the beginning that it would merely be a reverse engineering effort, and that it would likely lag a bit behind the changes in the main client. It was meant as a help for engineers that are not well versed in C/C++ to enable them to contribute by creating new clients, but the satoshi client would always be the de-facto standard. With the move from Google Code to the Bitcoin.it wiki somehow this notion of it being a reverse engineering effort was lost and people started assuming that if the behavior of the satoshi client did not match the protocol description it was a bug on the client side. Instead it is because the reverse engineering of the protocol is incorrect or simply missing some details. Although the protocol description is far more complete than it was back when we started, I still don't feel comfortable giving it the name specification. I still believe that a client monoculture is bad for the system as a whole, because a single bug might bring down the whole network. Giving people the necessary tools to implement new clients brings stability. I do understand the criticism that writing a specification might hinder future development as it restricts the possible changes to the protocol, but isn't this already the case as long as we have legacy versions of the client participating in the network? I would also argue that having a specification allows an application independent review of the protocol to identify possible improvements and bugs. I think the protocol description has an important place in the development of Bitcoin, so much so that we pushed a long time ago to separate protocol version from the client version. I would love to see the protocol specification becoming official part of the bitcoin github repository, which would ideally be maintained alongside the satoshi client to keep it up to date. Regards, Christian Decker [1] https://bitcointalk.org/index.php?topic=231 -- Christian Decker On Thu, Oct 24, 2013 at 9:03 AM, Martin Sustrik wrote: > On 23/10/13 23:07, Pieter Wuille wrote: > >> In short, >> consistency is more important than correctness. > > That's a nice and concise way to put it and any potential protocol > documentation should start with a statement like that. > >> 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. > > One interesting question is whather alternative implementations are more > likely to get it wrong because the protocol description is wrong or > because the authors misunderstood the reference implementation source code. > > Extensive documentation of the source code, a la Knuth's literate > programming, may be some kind of a middle ground. > >> 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. > > Ok. Several people expressed an interest in the topic, so I'll give it a > try and see how it fares. > > Martin > > > ------------------------------------------------------------------------------ > 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