Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.175 as permitted sender)
	client-ip=209.85.220.175; envelope-from=etotheipi@gmail.com;
	helo=mail-vx0-f175.google.com; 
Message-ID: <4EBEA880.7010608@gmail.com>
Date: Sat, 12 Nov 2011 12:10:24 -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: Mike Hearn <mike@plan99.net>
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>
In-Reply-To: <CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------060806030403030407020405"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

This is a multi-part message in MIME format.
--------------060806030403030407020405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Maybe I'm new to this, but this doesn't make any sense.  I thought the 
point of the BIP was to collaborate to come up with a good solution.  
That's exactly what I want to do before I implement it in my software.  
After all, they are "Bitcoin Improvement *Proposals*."  It seems like 
EXACTLY what a BIP is for... just no one needs/should use it until it 
removes the "draft" marking.

As for the protocol on top of it, my BIP was not intended to address 
that.  It's only proposing how unsigned transactions can be serialized 
and users can collect addresses.  Whatever system you want to implement 
on top of it to exchange the data is up to the developer.  My only 
motivation is that if the user clicks "Save this proposal to file", that 
any client can use the resulting file, just the same way we serialize 
any other blockdata that has a consistent representation.

-Alan


On 11/12/2011 11:58 AM, Mike Hearn wrote:
> Please don't create BIPs that don't have any actual implementation 
> behind them. Design discussion is fine but the mailing list works for 
> that.
>
> If I were going to implement escrow transactions in BitCoinJ it would 
> not matter what was written here. I'd just implement the design I 
> thought made sense. If that design was later adopted by others it can 
> be documented and agreed upon in a BIP, just like a regular RFC.
>
> For what it's worth I would not attempt to send half-valid escrow 
> transactions through the p2p network, not even using the overlay 
> networks the protocol already supports. A correct escrow protocol 
> requires the seller to challenge the dispute mediator with the public 
> key to be sure they actually own it, and the simplest way to do that 
> is to leverage the existing DNS/EV-SSL infrastructure with a "sign 
> this nonce" HTTP request.
>
> BIPs should not be a place for people to come up with armchair 
> designs, because a design with no corresponding implementation is 
> likely to be full of problems. Let's revisit this once I can install 
> some software on my laptop, my server, and a friends server, and do a 
> 3-way mediated transaction between them.


--------------060806030403030407020405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Maybe I'm new to this, but this doesn't make any sense.  I thought
    the point of the BIP was to collaborate to come up with a good
    solution.  That's exactly what I want to do before I implement it in
    my software.  After all, they are "Bitcoin Improvement <b>Proposals</b>." 
    It seems like EXACTLY what a BIP is for... just no one needs/should
    use it until it removes the "draft" marking.<br>
    <br>
    As for the protocol on top of it, my BIP was not intended to address
    that.  It's only proposing how unsigned transactions can be
    serialized and users can collect addresses.  Whatever system you
    want to implement on top of it to exchange the data is up to the
    developer.  My only motivation is that if the user clicks "Save this
    proposal to file", that any client can use the resulting file, just
    the same way we serialize any other blockdata that has a consistent
    representation.<br>
    <br>
    -Alan<br>
    <br>
    <br>
    <br>
    On 11/12/2011 11:58 AM, Mike Hearn wrote:
    <blockquote
cite="mid:CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com"
      type="cite">Please don't create BIPs that don't have any actual
      implementation behind them. Design discussion is fine but the
      mailing list works for that.
      <div><br>
      </div>
      <div>If I were going to implement escrow transactions in BitCoinJ
        it would not matter what was written here. I'd just implement
        the design I thought made sense. If that design was later
        adopted by others it can be documented and agreed upon in a BIP,
        just like a regular RFC.</div>
      <div><br>
      </div>
      <div>For what it's worth I would not attempt to send half-valid
        escrow transactions through the p2p network, not even using the
        overlay networks the protocol already supports. A correct escrow
        protocol requires the seller to challenge the dispute mediator
        with the public key to be sure they actually own it, and the
        simplest way to do that is to leverage the existing DNS/EV-SSL
        infrastructure with a "sign this nonce" HTTP request. </div>
      <div><br>
      </div>
      <div>BIPs should not be a place for people to come up with
        armchair designs, because a design with no corresponding
        implementation is likely to be full of problems. Let's revisit
        this once I can install some software on my laptop, my server,
        and a friends server, and do a 3-way mediated transaction
        between them.</div>
    </blockquote>
    <br>
  </body>
</html>

--------------060806030403030407020405--