Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-ww0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <4EBEA880.7010608@gmail.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
	<200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
	<4EBB3E68.6060402@gmail.com>
	<CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com>
	<4EBBCA0D.9060906@gmail.com>
	<CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
	<4EBEA880.7010608@gmail.com>
Date: Sat, 12 Nov 2011 18:16:02 +0100
Message-ID: <CANEZrP0LERYWrHmxzZYvzNauVF09YjLkHbPB=uty9v5p3Wck1g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=0016e64c1baed0b23a04b18cca80
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

--0016e64c1baed0b23a04b18cca80
Content-Type: text/plain; charset=UTF-8

BIPs are either "standards track" (affects everyone, represents consensus),
"informational" (ie basically just summarizing the authors viewpoints on
things) or "process".

My point is you can't have a credible standards track BIP until something
has been implemented end to end. I don't think it's a good plan to design
these things in isolation. You'll end up with bizarre user experiences
because of technical decisions taken months earlier that are now hard to
reverse. A working end to end implementation gives you the confidence to
say, yes, this is how it should work, because here's the demo and you can
see it works very well and the code is clean.

If your BIP is informational then no problems, but I don't think there's
much point in informational BIPs to be honest - it's easier to just write
an email or forum post summarizing your views on things. If you find it a
useful framework to write your thoughts in that's OK, but don't expect
implementors to follow what's written there just because it's a BIP. It
carries no more weight than any other document would.

--0016e64c1baed0b23a04b18cca80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BIPs are either &quot;standards track&quot; (affects everyone, represents c=
onsensus), &quot;informational&quot; (ie basically just summarizing the aut=
hors viewpoints on things) or &quot;process&quot;.=C2=A0<div><br></div><div=
>My point is you can&#39;t have a credible standards track BIP until someth=
ing has been implemented end to end. I don&#39;t think it&#39;s a good plan=
 to design these things in isolation. You&#39;ll end up with bizarre user e=
xperiences because of technical decisions taken months earlier that are now=
 hard to reverse. A working end to end implementation gives you the confide=
nce to say, yes, this is how it should work, because here&#39;s the demo an=
d you can see it works very well and the code is clean.</div>
<div><br></div><div>If your BIP is informational then no problems, but I do=
n&#39;t think there&#39;s much point in informational BIPs to be honest - i=
t&#39;s easier to just write an email or forum post summarizing your views =
on things. If you find it a useful framework to write your thoughts in that=
&#39;s OK, but don&#39;t expect implementors to follow what&#39;s written t=
here just because it&#39;s a BIP. It carries no more weight than any other =
document would.</div>
<div><br></div><div><br></div>

--0016e64c1baed0b23a04b18cca80--