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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1V7AOe-000769-Al
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 20:31:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V7AOc-0003tw-Gm
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 20:31:52 +0000
Received: by mail-ie0-f172.google.com with SMTP id 17so339057iea.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 07 Aug 2013 13:31:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.56.51 with SMTP id x19mr477340igp.12.1375907505135; Wed,
07 Aug 2013 13:31:45 -0700 (PDT)
Received: by 10.50.73.74 with HTTP; Wed, 7 Aug 2013 13:31:45 -0700 (PDT)
In-Reply-To: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
Date: Wed, 7 Aug 2013 22:31:45 +0200
Message-ID: <CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
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: 1V7AOc-0003tw-Gm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
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, 07 Aug 2013 20:31:52 -0000
On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
I don't like the wording for payment_uri "where the payment _may_ be
sent to obtain a paymentACK", or the fact that in the diagram it is
the client wallet broadcasting the transaction to the network.
In my opinion, it should ultimately become the responsibility of the
receiver to get the transaction confirmed. Of course, the sender may
help, and if the transaction does not confirm, no payment took place.
But one of the advantages direct negotiation offers, is that the
sender wallet does not need to remain online anymore to get the
transaction broadcast. I don't think it should be even required that
the sender wallet is connected to the P2P network at all. All they
need to do is construct a satisfactory transaction, and send it to the
merchant who cares about it.
I would suggest the wording, "if a payment_uri is specified, the
wallet application should try - and if necessary, retry - to submit
the transaction there, resulting in a paymentACK from the merchant.
Broadcasting the transaction on the P2P network is optional.". Perhaps
we should even discourage broadcasting before the paymentACK is
obtained, to make sure the merchant received it, together with the
metadata, to decrease the chances of money arriving at a merchant
without metadata (to minimize the cases where manual intervention is
needed).
--
Pieter
|
