Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RPGv1-000191-Cg for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 16:59:03 +0000 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; Received: from mail-ww0-f41.google.com ([74.125.82.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RPGv0-0001IB-C5 for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 16:59:03 +0000 Received: by wwf25 with SMTP id 25so3186943wwf.4 for ; Sat, 12 Nov 2011 08:58:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.17 with SMTP id b17mr2957224wef.50.1321117136201; Sat, 12 Nov 2011 08:58:56 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.216.37.203 with HTTP; Sat, 12 Nov 2011 08:58:56 -0800 (PST) In-Reply-To: <4EBBCA0D.9060906@gmail.com> References: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com> <4EBB3E68.6060402@gmail.com> <4EBBCA0D.9060906@gmail.com> Date: Sat, 12 Nov 2011 17:58:56 +0100 X-Google-Sender-Auth: mLb2q3LOU_MPix3BNXhx8LfqnAY Message-ID: From: Mike Hearn To: Alan Reiner Content-Type: multipart/alternative; boundary=0016e6d975ae9c2a4204b18c8d5b 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: 1RPGv0-0001IB-C5 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 16:59:03 -0000 --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'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 Bit= CoinJ 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 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 "sign this nonce" H= TTP request.=C2=A0

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'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.
--0016e6d975ae9c2a4204b18c8d5b--