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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Te6iY-0001E1-7m
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Nov 2012 16:12:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f47.google.com;
Received: from mail-la0-f47.google.com ([209.85.215.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Te6iU-0007HI-EU
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Nov 2012 16:12:02 +0000
Received: by mail-la0-f47.google.com with SMTP id u2so11749438lag.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Nov 2012 08:11:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.114.100 with SMTP id jf4mr22363320lab.47.1354205511509;
Thu, 29 Nov 2012 08:11:51 -0800 (PST)
Received: by 10.112.40.73 with HTTP; Thu, 29 Nov 2012 08:11:51 -0800 (PST)
In-Reply-To: <20121128233619.GA6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
Date: Thu, 29 Nov 2012 11:11:51 -0500
Message-ID: <CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Roy Badami <roy@gnomon.org.uk>
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.
-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
(gavinandresen[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: 1Te6iU-0007HI-EU
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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, 29 Nov 2012 16:12:02 -0000
RE: Roy Badami's comments on edge cases around submitting a Payment
message to a merchant and then not receiving a timely response:
I agree, it is messy.
I'm hesitant to try to specify One True Way of handling it in the
spec; I've got a feeling that this might be a place where different
implementations might try different things, with the best
implementation winning.
For example, if some future nifty-keen Bitcoin client is re-using an
old Invoice to send a monthly subscription payment and they can't
contact the paymentURI, then the right thing is probably for it to
retry once a day for three or four days and if they all fail then give
up and tell the user that the service is no longer in business (or
changed their paymentURI without leaving behind a redirect).
If it has a single-use Invoice created a minute or two ago, the right
logic might be:
+ If the paymentURI is completely non-responsive, just error and
tell the user "payment failed"
+ If connected to the paymentURI and payment sent, but disconnected
before receiving a response, then try to send-to-self the coins to
cancel payment.
Again, I'm not at all sure that is the best way to handle it;
implementors have the right incentives to give their users the best
user experience, so I feel comfortable leaving the spec fuzzy for now.
--
--
Gavin Andresen
|
