[Bitcoin-development] BIP language on normative behavior

Amir Taaki zgenjix at yahoo.com
Wed Dec 21 00:59:00 UTC 2011

A few weeks back I was in discussion with the IANA on getting a bitcoin URI accepted in the standard. As a prerequisite I had to read 5 huge documents. I did not end up writing that RFC.

Skilled developers have even less time than I do. While this particular RFC is really nice for keeping ambiguity at bay, it is one of many small rules that bring marginal improvements. "Rule creep" (like feature creep) starts off with good intentions but degenerates into a situation like Wikipedia or any other system with a heavy bureaucracy that can use the rules for lawyering against you.

We want to encourage skilled developers to help set the standards and participate in discussions. Beyond using good grammar and using the correct formatting (and I even help with those), I defer on the site of trusting common sense and human judgement :)

However this is a good RFC, and I will advise any future BIP contributors to read it. It offers good suggestions.

About what Luke says:

I kind of agree with him. The intention was to specify software stacks rather than end applications. This allows us to more carefully track software evolution and behaviour throughout the network. bitcoin-qt need not be tied to the Satoshi code-base and may in the future use other core systems through its intermediary layer. BitcoinJava has given rise to a bunch of other application like Android Bitcoin and MultiBit- however they are both BitcoinJava derivatives.

However BIPs are a community consensus thing. It depends on the mutual consent of everybody and if there is a commonly agreed sentiment against the wording of an Accepted (or even Active) BIP then it can be amended ad-hoc.

The purpose of BIPs is to enhance development by 1. providing a stable system environment for programmers to work towards an accepted standard 2. serve as an equaliser for smaller groups (the third party clients vs the current behemoth client) by giving them a voice or platform.

And they can only function by those who want them to function.

But personally, I really do think splitting bitcoin-qt into XXX and bitcoin-qt is a smart idea. Starting from lowest to top part of the system is smart: http://www.useragentstring.com/pages/Firefox/

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110613 Firefox/6.0a2

Mozilla is the application suite (Mozilla Thunderbird, Mozilla Firefox, ...)

Gecko is the rendering engine
Firefox is the end application

In the original intention for BIP_0014, that would map to:


With something like WebKit, it becomes easy to see why that would be useful. You can suddenly do a network wide scan of all browsers using WebKit, rather than having to maintain a database of all WebKit enabled browsers.

So if this is contentious.

Then discuss. I'll update the BIP according to what everyone decides they like.


 From: Gregory Maxwell <gmaxwell at gmail.com>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net> 
Sent: Monday, December 19, 2011 10:29 PM
Subject: [Bitcoin-development] BIP language on normative behavior
I've been arguing with Luke-JR on IRC about the interpenetration of
BIP_0014—  Gavin's recent commit uses the same version string for the
GUI interface and the daemon mode.

Luke believes this is a _violation_ of BIP_0014 and an error in
judgement on Gavin's part, and a failure to conform to the community
adopted standard. I believe Luke is mistaken: that BIP_0014 actually
don't have mandatory requirements for what you put in the version
field and even if it did, that they are in fact the same software and
should have the same name.

I don't think an agreement is likely on the second point, but the
first point highlights some ambiguity in the interpretation of BIP
language. E.g. What is permitted vs encouraged vs required.

There is well established standard language for this purpose:


I strongly recommend that all BIPs be written using the RFC2119
keywords where appropriate.

Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111220/eb203e2a/attachment.html>

More information about the bitcoin-dev mailing list