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
111
112
113
|
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 <roy@gnomon.org.uk>) id 1TdrRw-0007fv-R5
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Nov 2012 23:53:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1TdrRq-00063j-In
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Nov 2012 23:53:52 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id qASNaJ7H007000
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Wed, 28 Nov 2012 23:36:24 GMT (envelope-from roy@darla.gnomon.org.uk)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id qASNaJXO006999;
Wed, 28 Nov 2012 18:36:19 -0500 (EST) (envelope-from roy)
Date: Wed, 28 Nov 2012 18:36:19 -0500
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20121128233619.GA6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -1.9 (-)
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 SPF_PASS SPF: sender matches SPF record
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1TdrRq-00063j-In
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: Wed, 28 Nov 2012 23:53:53 -0000
> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.
I'm not sure I understand the rationale for this. In the above
scenario the buyer has no way to determine whether the merchant still
has a copy of the transaction that they could broadcast in future.
Maybe there is simply a systems problem at the merchant which has
temporarily delayed the transaction broadcast. Or maybe a dishonest
merchant deliberately engineered this situation in an attempt to
mislead the buyer as to the status of their payment.
Either way, having the buyer think the coins have been returned to
their wallet - only to disappear from their wallet again at some later
time - would seriously damage user confidence in Bitcoin IMHO.
It seems to me that the first thing the buyer should do given the
protocol as it stands is simply resend the Payment message - if there
was a temporary problem then resending the payment message (with the
same signed transation) might resolve the sitution.
If after several retries the status of the transaction is still
undefined then it's really not clear what to do, but it seems
desireable to have the client take steps so that it can return to a
state of certainly about its wallet balance as quickly as possible.
Two things I can imagine that the buyer might want their client to do
at this point are:
* broadcast the transaction itself, so they are sure the payment
transaction will make it into the blockchain without any further
action on their part, or
* invalidate the transaction by immediately broadcasting a
pay-to-self transaction that spends one or more of the same outputs
that the payment transaction spends (and treat the funds as part of
the unconfirmed balance until this pay-to-self transaction
confirms). This ensures the merchant can't subsequently use a
transaction which the buyer thinks has failed
It seems to me it would be simpler and cleaner if the buyer just
always broadcasted the transaction on the p2p network, regardless of
whether the Invoice includes a receiptURI. If a receiptURI is
included, the buyer's client would also include the transaction in the
Purchase message. The merchant then tries to broadcast the
transaction as well (unless their bitcoind has already seen it, which
may well be the common case). This approach seems to me to have fewer
nasty edge cases.s
roy
|
