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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1V7Qxw-00085X-7m
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Aug 2013 14:13:24 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.178 as permitted sender)
client-ip=209.85.223.178; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f178.google.com;
Received: from mail-ie0-f178.google.com ([209.85.223.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V7Qxv-0004u4-A6
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Aug 2013 14:13:24 +0000
Received: by mail-ie0-f178.google.com with SMTP id f4so1889665iea.37
for <bitcoin-development@lists.sourceforge.net>;
Thu, 08 Aug 2013 07:13:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.66.200 with SMTP id q8mr2202913ici.25.1375971198011; Thu,
08 Aug 2013 07:13:18 -0700 (PDT)
Received: by 10.50.73.74 with HTTP; Thu, 8 Aug 2013 07:13:17 -0700 (PDT)
In-Reply-To: <CABsx9T3BgjYnsi_UgRM7r0auUgA6BMFjEbSy8kNs_uLBiak8ow@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
<20130807214757.GA45156@giles.gnomon.org.uk>
<CAPg+sBhTYTiW-7btDuNJKqv8nMiZTUzMU2c+N+YcUVf1EejNJA@mail.gmail.com>
<20130807220358.GB45156@giles.gnomon.org.uk>
<CABsx9T3BgjYnsi_UgRM7r0auUgA6BMFjEbSy8kNs_uLBiak8ow@mail.gmail.com>
Date: Thu, 8 Aug 2013 16:13:17 +0200
Message-ID: <CAPg+sBhjZCAZvaj5VjWaiQskv1fYb7iokWbJ+hdbLi893qVP=g@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: 1V7Qxv-0004u4-A6
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: Thu, 08 Aug 2013 14:13:24 -0000
On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
> the bitcoin address is optional:
>
> "If the "request" parameter is provided and backwards compatibility is
> not required, then the bitcoin address portion of the URI may be
> omitted (the URI will be of the form: bitcoin:?request=... )."
Sounds good.
I'd still like to see some effort to avoid losing metadata and
reducing the responsibilities of the sender.
I see there's an implementation difficulty in avoiding to broadcast a
transaction, but for example, if a payment_uri is specified, and it
cannot be contacted (at all), the transaction should fail. As soon as
you manage to connect, and have at least attempted to submit the
transaction, the merchant may have received it, and you want to mark
the coins spent, so store it after that point. But without such
protection we'll likely see a unnecessary payments happening without
metadata, when the payment server cannot be contacted for some reason.
Also, the receiver most certainly needs a P2P implementation (and
probably a strongly validating one) to verify incoming transactions,
so having him broadcast it shouldn't be hard. I don't think the client
should be required to stay online to broadcast at all, after a
paymentACK is received. The transaction arrived safely at that point.
--
Pieter
|
