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
114
115
116
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1W2ll1-0001vx-N6
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 17:57:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.171 as permitted sender)
client-ip=209.85.223.171; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f171.google.com;
Received: from mail-ie0-f171.google.com ([209.85.223.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W2ll0-0005gd-M8
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Jan 2014 17:57:03 +0000
Received: by mail-ie0-f171.google.com with SMTP id to1so4277211ieb.2
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 Jan 2014 09:56:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.43.155.147 with SMTP id li19mr1322083icc.94.1389635817413;
Mon, 13 Jan 2014 09:56:57 -0800 (PST)
Received: by 10.50.90.42 with HTTP; Mon, 13 Jan 2014 09:56:57 -0800 (PST)
In-Reply-To: <lb18l6$nu2$1@ger.gmane.org>
References: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
<lb18l6$nu2$1@ger.gmane.org>
Date: Mon, 13 Jan 2014 18:56:57 +0100
Message-ID: <CAPg+sBji5sFWZ_mDVXKKwkyeGYDbLmvwau457nmntT_NgTT+Sw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
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: 1W2ll0-0005gd-M8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 17:57:03 -0000
On Mon, Jan 13, 2014 at 6:44 PM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> On 01/13/2014 05:43 PM, Pieter Wuille wrote:
>
>> 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).
I want to avoid the case where a transaction confirms, but the
associated payment is not delivered. If there is a reasonable chance
that this case occurs in normal operation, it means the payment
transmission cannot be relied upon.
On the other hand, if the payment gets sent, but the transaction is
not broadcasted, it can be broadcasted by the receiver (who has much
more reason to do so; he wants to spend his money).
>
> Can you explain what the problem is here? The payment message can be
> transmitted after the payment has been received through the P2P network.
> Am I missing something?
So, yes, sending on the P2P network is fine, as long as everything is
done to get the payment delivered. Not broadcasting on P2P is just an
optimization that makes failures of not getting the transaction out
and not getting the payment delivered coincide better. I say just
optimization, as you can't rely on the fact that if the payment fails,
the transaction will also fail (the merchant may be malicious, make
the submission of the payment fail, but broadcast the transaction
anyway), so wallets must still be able to deal with this. Nonetheless,
I think it can increase the reliability of "payment being received for
otherwise confirming transactions".
>
> Furthermore, if we give up the robustness of the P2P network, we will
> likely end up with more failed payments. There is so much that can go
> wrong when trying to connect via HTTP (proxies etc.), Bluetooth
> endpoints can go away, etc. At least we should provide fallback
> payment_url's in this case.
That's a different issue. I'm very aware that payments over HTTP can
fail. The point is that I prefer the entire transaction to fail in
that case, instead, and focus on making the payment submission more
reliable.
>
> As for you proposal, just be aware I'd like to use the payment protocol
> for face to face payments as well. That meant payment request via NFC or
> QR, payment message and payment confirmations via Bluetooth. I think it
> can be done by putting a Bluetooth mac address into the payment_url.
I'm aware. What issues do you see?
--
Pieter
|
