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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1W8tMV-000586-Dc
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 15:17:03 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f175.google.com;
Received: from mail-ig0-f175.google.com ([209.85.213.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W8tMU-0007kp-2u
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 15:17:03 +0000
Received: by mail-ig0-f175.google.com with SMTP id uq10so17887834igb.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 30 Jan 2014 07:16:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.43.65.145 with SMTP id xm17mr11019474icb.35.1391095014701;
Thu, 30 Jan 2014 07:16:54 -0800 (PST)
Received: by 10.50.100.10 with HTTP; Thu, 30 Jan 2014 07:16:54 -0800 (PST)
In-Reply-To: <CABsx9T1jAobC_p9oa_PX8M7Bo6Db3=oBhPuhp5CXVHqTRb=Hng@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>
<CABsx9T1jAobC_p9oa_PX8M7Bo6Db3=oBhPuhp5CXVHqTRb=Hng@mail.gmail.com>
Date: Thu, 30 Jan 2014 16:16:54 +0100
Message-ID: <CAPg+sBiz1oXqsRTpQpVghTFupj6jsp5M-zDGKe7bjeUBHNMxUA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 HK_SCAM_S4 BODY: HK_SCAM_S4
-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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1W8tMU-0007kp-2u
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:17:03 -0000
On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>>
>> Is this truly the intent? That the merchant/processor takes full
>> responsibility for getting the TX confirmed?
>
>
> The intent is to give the customer a great experience. We could talk for
> months about whether having the wallet broadcast the transaction as soon as
> possible or having it wait for the merchant to respond with a PaymentACK is
> better. But I think we should let wallets experiment with different ways of
> doing it, and see what works best in practice.
Currently, with the specification and implementation in Bitcoin Core,
if a merchant wants to use the refund or memo feature, they need to
provide an alternative route for delivering that information to them
*before* the transaction is made, as sending the transaction may
result in the transfer of funds without knowing what to do with it (if
their receive server is down at the right time) and potnetially no way
to contact the sender. This makes these fields utterly useless.
This is not a matter of letting wallets experiment with the best
behaviour. This is removing the ability to rely on the payment
protocol being bidirectional.
I don't care whether wallets broadcast the transactions or not (they
can experiment with that as they like). But we should take measures to
prevent a transaction for being broadcast without the payment being
delivered. One way is never broadcasting the transaction yourself.
Another is retrying to send the payment if delivery fails.
Here is what I would suggest to add to the specification:
* If a payment_uri is specified, the client must attempt to send the
payment there.
* If a transaction is broadcast (which is permitted even if sending
the payment fails), a client should make a reasonable attempt of
delivering the payment (remembering, retrying, ...).
* If a paymentACK has been received, the client is no longer
responsible for broadcasting the transaction (but still may).
--
Pieter
|
