Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.41 as permitted sender)
	client-ip=74.125.82.41; envelope-from=mh.in.england@gmail.com;
	helo=mail-ww0-f41.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <4EBBCA0D.9060906@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>
Date: Sat, 12 Nov 2011 17:58:56 +0100
Message-ID: <CANEZrP2RrkJ-6A8fwhNX_xKYScrDqBYM1VgcoZFNLqX8GaQotQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6d975ae9c2a4204b18c8d5b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

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

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.

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

Please don&#39;t create BIPs that don&#39;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 Bit=
CoinJ it would not matter what was written here. I&#39;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&#39;s worth I would not attempt to send hal=
f-valid escrow transactions through the p2p network, not even using the ove=
rlay networks the protocol already supports. A correct escrow protocol requ=
ires 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 &quot;sign this nonce&quot; H=
TTP request.=C2=A0</div>
<div><br></div><div>BIPs should not be a place for people to come up with a=
rmchair designs, because a design with no corresponding implementation is l=
ikely to be full of problems. Let&#39;s revisit this once I can install som=
e software on my laptop, my server, and a friends server, and do a 3-way me=
diated transaction between them.</div>

--0016e6d975ae9c2a4204b18c8d5b--