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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
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 1We7h7-0000ma-RR
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 18:51:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We7h7-0000zK-0x
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 18:51:25 +0000
Received: by mail-ob0-f171.google.com with SMTP id uy5so5689033obc.30
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 11:51:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.17.132 with SMTP id o4mr13353128oed.34.1398538279667;
Sat, 26 Apr 2014 11:51:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Sat, 26 Apr 2014 11:51:19 -0700 (PDT)
In-Reply-To: <20140426183119.GB16440@savin>
References: <20140426112312.GA17949@savin>
<CANEZrP3VpsW_RNWUpw-gsQhXqLF4deOJJPHxGJUc8Gx_y0B9wA@mail.gmail.com>
<20140426183119.GB16440@savin>
Date: Sat, 26 Apr 2014 20:51:19 +0200
X-Google-Sender-Auth: VakTioTxg7yDHTvHqXMAdEx_JDc
Message-ID: <CANEZrP2O74111_PxG-yPYFj0x7wfXTUhCYpre_3=93iYk14fEw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e01294d0c5d4e2004f7f691ae
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: 1We7h7-0000zK-0x
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Jeremy Spilman <jeremy.spilman@gmail.com>
Subject: Re: [Bitcoin-development] Eliminating double-spends with two-party
self-escrow for high value transactions
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, 26 Apr 2014 18:51:26 -0000
--089e01294d0c5d4e2004f7f691ae
Content-Type: text/plain; charset=UTF-8
>
> Note how the mechanism I'm proposing is basically just a Jeremy
> Spilman-style micropayment channel(1) used for a single payment; I
> should have made that clear in my original post.
Right, that does make more sense. Yes, it's a good idea. The question is
whether wallet UI's can support it without being overly complex. We'd be
asking users to take extra steps to work around unintuitive limitations of
the protocol. Products that do that too much tend to get left for something
that "just works". But there may be a slick way to present it.
--089e01294d0c5d4e2004f7f691ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Note how the mechanism I'm proposing is basi=
cally just a Jeremy<br>
Spilman-style micropayment channel(1) used for a single payment; I<br>
should have made that clear in my original post.</blockquote><div><br></div=
><div>Right, that does make more sense. Yes, it's a good idea. The ques=
tion is whether wallet UI's can support it without being overly complex=
. We'd be asking users to take extra steps to work around unintuitive l=
imitations of the protocol. Products that do that too much tend to get left=
for something that "just works". But there may be a slick way to=
present it.=C2=A0</div>
</div></div></div>
--089e01294d0c5d4e2004f7f691ae--
|
