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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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 <kgreenek@gmail.com>) id 1WDTRm-0000Pt-F3
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Feb 2014 06:37:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.175 as permitted sender)
client-ip=209.85.160.175; envelope-from=kgreenek@gmail.com;
helo=mail-yk0-f175.google.com;
Received: from mail-yk0-f175.google.com ([209.85.160.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WDTRl-0005o8-PK
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Feb 2014 06:37:26 +0000
Received: by mail-yk0-f175.google.com with SMTP id 131so14092807ykp.6
for <bitcoin-development@lists.sourceforge.net>;
Tue, 11 Feb 2014 22:37:20 -0800 (PST)
X-Received: by 10.236.32.36 with SMTP id n24mr38322yha.116.1392187040295; Tue,
11 Feb 2014 22:37:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.170.94.66 with HTTP; Tue, 11 Feb 2014 22:37:00 -0800 (PST)
In-Reply-To: <CAEY8wq5=pAMTqDPM8yeCF+Z2=1GWmD0UDQdgacN1o3jAUh_BYA@mail.gmail.com>
References: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
<CANEZrP10z6_UAHD97mj22kVEGyXgHPQ2PdP_8RxHT5Py+xRP_A@mail.gmail.com>
<D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
<CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@mail.gmail.com>
<0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org>
<DBA255DB-4839-4C3A-BA62-BD3926995C12@kill-bill.org>
<CAEY8wq6F33814d2+97AqDoAicvh=0PigHZ03wHadMq6JqtQMLg@mail.gmail.com>
<EAEC76DA-A490-4A61-BFB7-611D4ADF1680@kill-bill.org>
<CAEY8wq5=pAMTqDPM8yeCF+Z2=1GWmD0UDQdgacN1o3jAUh_BYA@mail.gmail.com>
From: Kevin Greene <kgreenek@gmail.com>
Date: Tue, 11 Feb 2014 22:37:00 -0800
Message-ID: <CAEY8wq40RxeUYYJS2m=xq26iTd2NE64WR7QOUO0+yR-MJQCoxQ@mail.gmail.com>
To: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative; boundary=001a11c1c2d8ff6faf04f22fcd55
X-Spam-Score: -0.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
(kgreenek[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WDTRl-0005o8-PK
Cc: Pierre-Alexandre Meyer <pierre@kill-bill.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support
recurring payments
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, 12 Feb 2014 06:37:26 -0000
--001a11c1c2d8ff6faf04f22fcd55
Content-Type: text/plain; charset=ISO-8859-1
Sending this again and truncating since apparently the message body was too
long.
Thanks for humoring my questions!
>I think reporting such errors to the wallet would make complete sense.
However i am not clear why we would a separate url for that?
Hmm, thinking about this more, adding a simple status_code in
PaymentRequest would be a much easier way to achieve this. However,
continuing to think about this even more, maybe the simple memo field along
with an empty set of outputs is enough already.
In bitcoinj, right now the code will throw a
PaymentRequestException.InvalidOutputs exception if the set of outputs is
empty with a message of "No Outputs". Because of that, there isn't a good
way to tell the difference between a payment request that had no outputs
and a payment request that had some invalid output(s).
*Question to everyone:*
How does bitcoin-qt handle a PaymentRequest with no outputs?
--001a11c1c2d8ff6faf04f22fcd55
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"color:rgb(51,102,102=
)">Sending this again and truncating since apparently the message body was =
too long.</div><div class=3D"gmail_default" style=3D"color:rgb(51,102,102)"=
><br></div>
<div class=3D"gmail_default" style=3D"color:rgb(51,102,102)"><div class=3D"=
gmail_default" style=3D"font-family:arial,sans-serif;font-size:13px">Thanks=
for humoring my questions!</div><div class=3D"im" style=3D"font-family:ari=
al,sans-serif;font-size:13px">
<div class=3D"gmail_default" style=3D"color:rgb(51,102,102)"><span style=3D=
"color:rgb(34,34,34)"><br></span></div><div class=3D"gmail_default" style=
=3D"color:rgb(51,102,102)"><span style=3D"color:rgb(34,34,34)">>I think =
reporting such errors to the wallet would make complete sense. However i am=
not clear why we would a separate url for that?</span><br>
</div><div class=3D"gmail_default" style=3D"color:rgb(51,102,102)"><br></di=
v></div><div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;=
font-size:13px">Hmm, thinking about this more, adding a simple status_code =
in PaymentRequest would be a much easier way to achieve this. However, cont=
inuing to think about this even more, maybe the simple memo field along wit=
h an empty set of outputs is enough already.</div>
<div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-siz=
e:13px"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,s=
ans-serif;font-size:13px">In bitcoinj, right now the code will throw a Paym=
entRequestException.InvalidOutputs exception if the set of outputs is empty=
with a message of "No Outputs". Because of that, there isn't=
a good way to tell the difference between a payment request that had no ou=
tputs and a payment request that had some invalid output(s).</div>
<div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-siz=
e:13px"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,s=
ans-serif;font-size:13px"><b>Question to everyone:</b></div><div class=3D"g=
mail_default" style=3D"font-family:arial,sans-serif;font-size:13px">
How does bitcoin-qt handle a PaymentRequest with no outputs?</div></div></d=
iv>
--001a11c1c2d8ff6faf04f22fcd55--
|
