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
|
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 1WimWl-00053N-55
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 15:15:59 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WimWk-0006o3-0a
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 15:15:59 +0000
Received: by mail-oa0-f43.google.com with SMTP id l6so5061401oag.30
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 May 2014 08:15:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr4710597oeb.81.1399648552502;
Fri, 09 May 2014 08:15:52 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Fri, 9 May 2014 08:15:52 -0700 (PDT)
In-Reply-To: <20140509150325.GA30436@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
<20140509150325.GA30436@savin>
Date: Fri, 9 May 2014 17:15:52 +0200
X-Google-Sender-Auth: tATCsiTv9xuXnaqxPGYll_T4F20
Message-ID: <CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7b41cd28c84b4204f8f9124a
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: 1WimWk-0006o3-0a
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
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: Fri, 09 May 2014 15:15:59 -0000
--047d7b41cd28c84b4204f8f9124a
Content-Type: text/plain; charset=UTF-8
>
> Of course we quickly rejected the idea of depending solely on a
> communications backchannel to retrieve funds. Any communications medium
> that isn't the blockchain makes the payment non-atomic
Yes, I know you rejected this design, which is why I'm now proposing it
instead. I think you made the wrong design call, but at any rate, it's
something reasonable people can disagree on.
Payment messages are sent directly to the merchant, who takes
responsibility for broadcast. Once you delivered transactions to the
merchant successfully, from your perspective the payment is made. A good
store and forward network doesn't allow messages to go missing - email is
an example of that (ignoring spam filters that explicitly want messages to
go missing). It either gets delivered or it doesn't. So I'm not worried
about atomicity.
--047d7b41cd28c84b4204f8f9124a
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">Of course we quickly rejected the idea of depend=
ing solely on a<br>
communications backchannel to retrieve funds. Any communications medium<br>
that isn't the blockchain makes the payment non-atomic</blockquote><div=
><br></div><div>Yes, I know you rejected this design, which is why I'm =
now proposing it instead. I think you made the wrong design call, but at an=
y rate, it's something reasonable people can disagree on.</div>
<div><br></div><div>Payment messages are sent directly to the merchant, who=
takes responsibility for broadcast. Once you delivered transactions to the=
merchant successfully, from your perspective the payment is made. A good s=
tore and forward network doesn't allow messages to go missing - email i=
s an example of that (ignoring spam filters that explicitly want messages t=
o go missing). It either gets delivered or it doesn't. So I'm not w=
orried about atomicity.</div>
</div></div></div>
--047d7b41cd28c84b4204f8f9124a--
|
