summaryrefslogtreecommitdiff
path: root/de/2d87f35f2e5408118b0a7172a8c8e7a37f6c8a
blob: 963ec758ec540b2e89fcc9218c48980d72260471 (plain)
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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W8t7y-0000sr-GE
	for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 15:02:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.180 as permitted sender)
	client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f180.google.com; 
Received: from mail-ob0-f180.google.com ([209.85.214.180])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W8t7x-0002S8-0M
	for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 15:02:02 +0000
Received: by mail-ob0-f180.google.com with SMTP id wp4so3576235obc.39
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 30 Jan 2014 07:01:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.84.199 with SMTP id b7mr1518541oez.55.1391094112127; Thu,
	30 Jan 2014 07:01:52 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Thu, 30 Jan 2014 07:01:52 -0800 (PST)
In-Reply-To: <CAJHLa0MVbDnC0i+uT9Sahxk8ht9R5ztSJ-kOU5ERapeVibH9eg@mail.gmail.com>
References: <lc409d$4mf$1@ger.gmane.org>
	<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
	<CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com>
	<CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com>
	<CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com>
	<CAJHLa0MVbDnC0i+uT9Sahxk8ht9R5ztSJ-kOU5ERapeVibH9eg@mail.gmail.com>
Date: Thu, 30 Jan 2014 16:01:52 +0100
X-Google-Sender-Auth: ZaWwKFVElsbwQmk2-WmvdQ64S9c
Message-ID: <CANEZrP2nm4=Co48TebL1b1gQVP4oPG0RePa01cqRe1Zqod2gwg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0102dc826710f004f13156dc
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: 1W8t7x-0002S8-0M
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
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: Thu, 30 Jan 2014 15:02:02 -0000

--089e0102dc826710f004f13156dc
Content-Type: text/plain; charset=UTF-8

>
> Is this truly the intent?  That the merchant/processor takes full
> responsibility for getting the TX confirmed?


As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumably a part of that as it'd make no sense for
a merchant to give that assurance and decide they don't care about the
money.

But nothing stops the user broadcasting the tx as well, once the receiver
has given that assurance.

--089e0102dc826710f004f13156dc
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"><div class=3D"im"><span style=3D"color:rgb(34,34=
,34)">Is this truly the intent? =C2=A0That the merchant/processor takes ful=
l</span><br>
</div>
responsibility for getting the TX confirmed?</blockquote><div><br></div><di=
v>As per Gavin at the top of the thread, the intent is to give the customer=
 reassurance that their payment will be processed. The merchant trying to g=
et the tx confirmed is presumably a part of that as it&#39;d make no sense =
for a merchant to give that assurance and decide they don&#39;t care about =
the money.</div>
<div><br></div><div>But nothing stops the user broadcasting the tx as well,=
 once the receiver has given that assurance.=C2=A0</div></div></div></div>

--089e0102dc826710f004f13156dc--