Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com;
	helo=mail-vw0-f47.google.com; 
Message-ID: <4EBB3E68.6060402@gmail.com>
Date: Wed, 09 Nov 2011 22:00:56 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
	<200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
In-Reply-To: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
Content-Type: multipart/alternative;
	boundary="------------090705060302020707080007"
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

This is a multi-part message in MIME format.
--------------090705060302020707080007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

The purpose of creating BIP 0010 now, is to encourage a standard that 
developers /want/ to adopt, from the outset.  Every developer who is 
planning to touch multi-signature transactions, is going to have to 
solve the problem of multi-sig tx exchanges, eventually.  By offering an 
excellent solution before they've started asking the question, there's a 
good chance people will use it.   Hear me out...

Protocols get fragmented when there's multiple competing ways to do 
something, each having some advantages the others don't have.  This 
leads to developers with differing priorities picking different ones, or 
creating their own.   However, I believe that the problem BIP 0010 seeks 
to solve is a fairly straightforward problem.  There's not a lot of 
variety in the solutions that could compete against it.  People just 
need a way to pass this data around, and they want it to be as 
convenient to use, and as easy to implement as possible.  In that sense, 
I think BIP 0010 (or some future variant) is fairly optimal as a 
building block for higher-level protocols.

If anyone has ideas for why someone would want to create a competing 
idea to BIP 0010 (besides not being aware of it when they start), I'd 
like to discuss it.  I'm fairly confident that any such ideas could just 
be added to BIP 0010 and thus reset the question of why anyone would 
need a competing idea.


On 11/09/2011 03:03 PM, Michael Grønager wrote:
> My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the
>
> /M


--------------090705060302020707080007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    The purpose of creating BIP 0010 now, is to encourage a standard
    that developers <i>want</i> to adopt, from the outset.&nbsp; Every
    developer who is planning to touch multi-signature transactions, is
    going to have to solve the problem of multi-sig tx exchanges,
    eventually.&nbsp; By offering an excellent solution before they've
    started asking the question, there's a good chance people will use
    it.&nbsp;&nbsp; Hear me out...<br>
    <br>
    Protocols get fragmented when there's multiple competing ways to do
    something, each having some advantages the others don't have.&nbsp; This
    leads to developers with differing priorities picking different
    ones, or creating their own. &nbsp; However, I believe that the problem
    BIP 0010 seeks to solve is a fairly straightforward problem.&nbsp;
    There's not a lot of variety in the solutions that could compete
    against it.&nbsp; People just need a way to pass this data around, and
    they want it to be as convenient to use, and as easy to implement as
    possible.&nbsp; In that sense, I think BIP 0010 (or some future variant)
    is fairly optimal as a building block for higher-level protocols.&nbsp; <br>
    <br>
    If anyone has ideas for why someone would want to create a competing
    idea to BIP 0010 (besides not being aware of it when they start),
    I'd like to discuss it.&nbsp; I'm fairly confident that any such ideas
    could just be added to BIP 0010 and thus reset the question of why
    anyone would need a competing idea.<br>
    <br>
    <br>
    <br>
    On 11/09/2011 03:03 PM, Michael Gr&oslash;nager wrote:
    <blockquote
      cite="mid:200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com"
      type="cite">
      <pre wrap="">
My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the 

/M
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090705060302020707080007--