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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1W2kc7-0002Ap-My
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 16:43:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.178 as permitted sender)
client-ip=209.85.213.178; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f178.google.com;
Received: from mail-ig0-f178.google.com ([209.85.213.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W2kc6-0002Ja-VT
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 16:43:47 +0000
Received: by mail-ig0-f178.google.com with SMTP id uq10so2402140igb.5
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 Jan 2014 08:43:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.43.65.145 with SMTP id xm17mr21609572icb.35.1389631421670;
Mon, 13 Jan 2014 08:43:41 -0800 (PST)
Received: by 10.50.90.42 with HTTP; Mon, 13 Jan 2014 08:43:41 -0800 (PST)
Date: Mon, 13 Jan 2014 17:43:41 +0100
Message-ID: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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
(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: 1W2kc6-0002Ja-VT
Subject: [Bitcoin-development] Payment protocol and reliable Payment messages
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: Mon, 13 Jan 2014 16:43:48 -0000
Hi all,
while thinking about what use cases the stealth addresses covers, in
particular in addition to the payment protocol, I found it useful to
bring this up again.
currently, BIP70 says for "payment_url": Secure (usually https)
location where a Payment message (see below) may be sent to obtain a
PaymentACK.
The fact that this is optional makes the "memo" and "refund" and
"merchant_data" fields in the Payment message useless, as merchants
cannot rely on it, thus need to provide an alternative, thus nobody
would have a use for trying to use the in-Payment versions. If we
truly want the use of this Payment being sent be optional, I'd vote to
get rid of these and just send the transaction.
In particular in the case of more anonymous senders, if the Payment
message isn't sent, it may result in funds being transferred without a
way to know who to refund it to if something goes wrong.
That would be a pity. I think having bi-directional communication in
the protocol is one of the nicest things the payment protocol can add.
I would prefer to at least formulate it in the BIP as "location where
a Payment message must be attempted to be sent to". In case it fails,
it should probably be stored in the client and retried later.
As an optimization (and I believe this is what Mike plans to implement
in BitcoinJ), if a payment_url is present, it should be encouraged to
only send the payment there, and not broadcast the transaction at all
on the P2P network (minimizing the risk that the transaction confirms
without the payment being received; it can't be guaranteed however).
--
Pieter
|
