public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Date: Sat, 12 Nov 2011 18:16:02 +0100	[thread overview]
Message-ID: <CANEZrP0LERYWrHmxzZYvzNauVF09YjLkHbPB=uty9v5p3Wck1g@mail.gmail.com> (raw)
In-Reply-To: <4EBEA880.7010608@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1239 bytes --]

  reply	other threads:[~2011-11-12 17:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 10:22 [Bitcoin-development] multisig, op_eval and lock_time/sequence Michael Grønager
2011-11-09 14:43 ` Alan Reiner
2011-11-09 15:22   ` Alan Reiner
2011-11-09 19:13 ` Gavin Andresen
2011-11-09 20:02   ` Gavin Andresen
2011-11-09 20:31     ` Michael Grønager
2011-11-09 21:18       ` Gavin Andresen
2011-11-09 21:32         ` Joel Joonatan Kaartinen
2011-11-09 22:13     ` theymos
2011-11-09 20:03   ` Michael Grønager
2011-11-10  3:00     ` Alan Reiner
2011-11-10  9:55       ` Michael Grønager
2011-11-10 12:56         ` Alan Reiner
2011-11-12 16:58           ` Mike Hearn
2011-11-12 17:10             ` Alan Reiner
2011-11-12 17:16               ` Mike Hearn [this message]
2011-11-12 17:25                 ` Alan Reiner
2011-11-12 17:38                   ` Mike Hearn

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='CANEZrP0LERYWrHmxzZYvzNauVF09YjLkHbPB=uty9v5p3Wck1g@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=etotheipi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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