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
105
106
107
108
109
110
111
112
113
114
115
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
X-Google-Sender-Auth: mLb2q3LOU_MPix3BNXhx8LfqnAY
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
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 <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 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.=
<div><br></div><div>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.</div>
<div><br></div><div>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</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'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--
|
