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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1Te7ao-0007GL-7N
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Nov 2012 17:08:06 +0000
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Te7ag-0001B2-S0
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Nov 2012 17:08:06 +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 qATH7DfG022901
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Thu, 29 Nov 2012 17:07:19 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 qATH7D8R022900;
Thu, 29 Nov 2012 12:07:13 -0500 (EST) (envelope-from roy)
Date: Thu, 29 Nov 2012 12:07:13 -0500
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20121129170713.GD6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -1.1 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain -0.8 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Te7ag-0001B2-S0
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 17:08:06 -0000
I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message to the merchant containing the
proposed Outputs and a copy of the merchant_data along with the txid.
Assuming the proposed payment is accepted as valid by the merchant,
the buyer's client simply broadcasts the pre-prepared transaction in
the normal way, and it is the merchant's responsibility to watch for
this transaction to arrive over the p2p network/blockchain to complete
the purchase. (So if the merchant rejects the purchase at the
ValidatePurchase stage, they never get to see the transaction that the
buyer prepared, and there's therefore no need for a send-to-self to
cancel it.)
An optional RequestReceipt message (perhaps containing the
merchant_data and txid) can be sent by the client after the
transaction has been broadcast - but by making this explicitly
optional it forces the merchant to rely on seeing the bitcoin
transaction to 'commit' the payment and not on the RequestReceipt
message.
As far as I can see this proposal has no edge cases where the buyer
and merchant have differing ideas as to whether the transaction has
'comitted' - or at least, no more edge cases than the standard bitcoin
protocol has.
roy
|
