Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RPHWv-0000Dx-LC for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 17:38:13 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RPHWu-0008SB-PU for bitcoin-development@lists.sourceforge.net; Sat, 12 Nov 2011 17:38:13 +0000 Received: by wwf27 with SMTP id 27so2010065wwf.10 for ; Sat, 12 Nov 2011 09:38:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.197.199 with SMTP id el7mr10973546wbb.12.1321119486602; Sat, 12 Nov 2011 09:38:06 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.216.37.203 with HTTP; Sat, 12 Nov 2011 09:38:06 -0800 (PST) In-Reply-To: <4EBEABFC.2080802@gmail.com> References: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com> <4EBB3E68.6060402@gmail.com> <4EBBCA0D.9060906@gmail.com> <4EBEA880.7010608@gmail.com> <4EBEABFC.2080802@gmail.com> Date: Sat, 12 Nov 2011 18:38:06 +0100 X-Google-Sender-Auth: BI93nz60HyQuazG0F-dvpDJQbUI Message-ID: From: Mike Hearn To: Alan Reiner Content-Type: multipart/alternative; boundary=0015174c104cb46d3b04b18d19fa 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: 1RPHWu-0008SB-PU 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 17:38:13 -0000 --0015174c104cb46d3b04b18d19fa Content-Type: text/plain; charset=UTF-8 Sure, of course, as long as it's clearly labelled as just your thoughts, no issues. For dispute mediation the way I'd start is playing around with some UI design stuff and a toy protocol underneath. Once the process is smooth from the users POV (no seeing binary blobs disguised as text) then it should become clearer what steps the protocol needs and what order they need to come in. Specific feedback on this format - as far as I can tell the format represents a subset of the regular bitcoin transaction format? Couldn't you just serialize a Bitcoin CTransaction structure with the txins containing the output scripts? --0015174c104cb46d3b04b18d19fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure, of course, as long as it's clearly labelled as just your thoughts= , no issues.

For dispute mediation the way I'd start= is playing around with some UI design stuff and a toy protocol underneath.= Once the process is smooth from the users POV (no seeing binary blobs disg= uised as text) then it should become clearer what steps the protocol needs = and what order they need to come in.

Specific feedback on this format - as far as I can tell= the format represents a subset of the regular bitcoin transaction format? = Couldn't you just serialize a Bitcoin CTransaction structure with the t= xins containing the output scripts?
--0015174c104cb46d3b04b18d19fa--