1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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>
<4EBEA880.7010608@gmail.com>
<CANEZrP0LERYWrHmxzZYvzNauVF09YjLkHbPB=uty9v5p3Wck1g@mail.gmail.com>
<4EBEABFC.2080802@gmail.com>
Date: Sat, 12 Nov 2011 18:38:06 +0100
X-Google-Sender-Auth: BI93nz60HyQuazG0F-dvpDJQbUI
Message-ID: <CANEZrP1O=A02KcQWNCLdjtaGGeKnWhP54H6n3aXBecE5Fdjfxg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
--0015174c104cb46d3b04b18d19fa--
|
