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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RPHBa-00038s-77 for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 17:16:10 +0000 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; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RPHBZ-0007IR-7i for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 17:16:10 +0000 Received: by wwf27 with SMTP id 27so1996617wwf.10 for ; Sat, 12 Nov 2011 09:16:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.221.135 with SMTP id r7mr149020wep.50.1321118163054; Sat, 12 Nov 2011 09:16:03 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.216.37.203 with HTTP; Sat, 12 Nov 2011 09:16:02 -0800 (PST) In-Reply-To: <4EBEA880.7010608@gmail.com> References: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com> <4EBB3E68.6060402@gmail.com> <4EBBCA0D.9060906@gmail.com> <4EBEA880.7010608@gmail.com> Date: Sat, 12 Nov 2011 18:16:02 +0100 X-Google-Sender-Auth: 3vD9GqPusJrOpRugZvzBJ86Dgr4 Message-ID: From: Mike Hearn To: Alan Reiner Content-Type: multipart/alternative; boundary=0016e64c1baed0b23a04b18cca80 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1RPHBZ-0007IR-7i Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 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: Sat, 12 Nov 2011 17:16:10 -0000 --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 "standards track" (affects everyone, represents c= onsensus), "informational" (ie basically just summarizing the aut= hors viewpoints on things) or "process".=C2=A0

My point is you can't have a credible standards track BIP until someth= ing 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 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's the demo an= d you can see it works very well and the code is clean.

If your BIP is informational then no problems, but I do= n't think there's much point in informational BIPs to be honest - i= t'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 t= here just because it's a BIP. It carries no more weight than any other = document would.


--0016e64c1baed0b23a04b18cca80--