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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <christophe.biocca@gmail.com>) id 1WINKl-0003GE-Lm
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 19:06:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.43 as permitted sender)
client-ip=209.85.160.43;
envelope-from=christophe.biocca@gmail.com;
helo=mail-pb0-f43.google.com;
Received: from mail-pb0-f43.google.com ([209.85.160.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WINKk-0001Ct-Bc
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 19:06:27 +0000
Received: by mail-pb0-f43.google.com with SMTP id ma3so5861104pbc.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Feb 2014 11:06:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.228.138 with SMTP id si10mr1447730pbc.13.1393355180502;
Tue, 25 Feb 2014 11:06:20 -0800 (PST)
Received: by 10.68.146.72 with HTTP; Tue, 25 Feb 2014 11:06:20 -0800 (PST)
In-Reply-To: <CANAnSg3LF6m9u-MV8XiiomMPrbihJh7hm5o=menOWY71bLkdAg@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>
<CAEY8wq40RxeUYYJS2m=xq26iTd2NE64WR7QOUO0+yR-MJQCoxQ@mail.gmail.com>
<5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org>
<81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org>
<CANEZrP0-LqFC8N500=mnKbKE+=UtFw_Y5cHR8JRC-zmmGsSAjA@mail.gmail.com>
<CANAnSg3LF6m9u-MV8XiiomMPrbihJh7hm5o=menOWY71bLkdAg@mail.gmail.com>
Date: Tue, 25 Feb 2014 14:06:20 -0500
Message-ID: <CANOOu=-uijS7TxYcC+MD_OPYbZ4BFg-Cy6qOHv5u=TiUq2JenQ@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@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
(christophe.biocca[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: 1WINKk-0001Ct-Bc
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: Tue, 25 Feb 2014 19:06:27 -0000
Given the enormous number of variations on time periods for a
recurring payment, might it be better to simple allow a list of
timestamps? It costs almost nothing, bandwidth wise, and shifts the
thinking to the merchant platform. That doesn't give you an infinite
time frame, but you just get a new list of timestamps every time you
pay the service.
Continuing that thought, is a "next_payment_time" field with each
incremental transaction enough to cover everything?
On Tue, Feb 25, 2014 at 1:40 PM, Drak <drak@zikula.org> wrote:
> Forgive me if I missed it, but the spec doesnt look like it can handle only
> handle periods of per week, per month, per quarter rather than 'n period'. I
> take Paypal as a reference example for subscription payments where you can
> set recurring to every: n days, n weeks, n months, n years. That way a
> quarterly payment is every 3 months. This fine granularity is necessary
> because sometime a payment scheme can be per 4 weekly rather than per
> monthly.
>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
> and you can drop quarterly since it's just expressed as per 3*monthly.
>
> Drak
>
>
> On 25 February 2014 16:29, Mike Hearn <mike@plan99.net> wrote:
>>
>> Hey there,
>>
>> So the essence of this protocol is as follows:
>>
>>
>> enum PaymentFrequencyType {
>> WEEKLY = 1;
>> MONTHLY = 2;
>> QUARTERLY = 3;
>> ANNUAL = 4;
>> }
>> message RecurringPaymentDetails {
>> // Namespace for the merchant such as org.foo.bar
>> required string merchant_id = 1;
>>
>>
>> // Id for the recurring subscription
>> required bytes subscription_id = 2;
>>
>>
>> // Contracts associated with a given subscription
>> repeated RecurringPaymentContract contracts = 3;
>>
>>
>> }
>> message RecurringPaymentContract {
>>
>>
>> // Unique id for a given contract
>> required bytes contract_id = 1;
>>
>>
>> // URL to poll to get the next PaymentRequest
>> required string polling_url = 2;
>>
>>
>> // Timestamp; when this contract starts
>> required uint64 starts = 3;
>>
>>
>> // Timestamp; when this contract should be considered invalid
>> optional uint64 ends = 4;
>>
>>
>> // Expected payment frequency
>> optional PaymentFrequencyType payment_frequency_type = 5;
>>
>>
>> // Max payment amount within that frequency (e.g. no more than 5
>> BTC per month)
>> optional uint64 max_payment_per_period = 6;
>>
>>
>> // Max payment amount (e.g. no more than 3 BTC per payment)
>> optional uint64 max_payment_amount = 7;
>>
>>
>> }
>>
>> I have the following comments:
>>
>> There's no need to serialize RecurringPaymentDetails as bytes here. It's
>> done that way outside of PaymentDetails in order to support digital
>> signatures over protobufs that may have extensions the wallet app isn't
>> aware of, but it's a pain and inside PaymentDetails (and therefore for most
>> extensions) it shouldn't be necessary. So you can just use "optional
>> RecurringPamentDetails recurring_payments = 8;"
>>
>> There's only 4 possibilities here for recurrences. That seems rather
>> restrictive. Is the cost of being more expressive really so high? Why not
>> allow more flexible specification of periods?
>>
>> If there's no payment_frequency_type field then what happens? A quirk of
>> protobufs to be aware of is that making an enum field "required" can hurt
>> backwards compatibility. Because it will be expressed using a languages
>> underlying enum type, if there's a new enum member added later old software
>> that attempts to deserialize this will throw exceptions because the new
>> "unknown" member would be unrepresentable in the old model. Making the field
>> optional avoids this problem (it will be treated as missing instead) but
>> means software needs to be written to know what to do when it can't read the
>> enum value / sees enum values from the future.
>>
>> I assume the amounts are specified in terms of satoshi, and timestamps are
>> UNIX time, but better to make that explicit.
>>
>> Seems there's an implicit value constraint that max_payment_amount <=
>> max_payment_per_period. What happens if that constraint is violated? Best to
>> document that.
>>
>> What's the "merchant ID" namespace thing about? What's it for? What
>> happens if I set my competitors merchant ID there?
>>
>> What's the "subscription ID"? Is this stuff not duplicative/redundant with
>> the existing merchant_data field?
>>
>> In what situations would you have >1 contract per payment request? I'm not
>> sure I understand why it's repeated. Presumably if there are zero contracts
>> included the data should be ignored, or an error thrown and the entire
>> payment request rejected? Which should it be?
>>
>> It's unclear to me given such a contract when the payment should actually
>> occur. For instance if it's "monthly" then what day in the month would the
>> payment occur?
>>
>> You'll notice I moved the comments to be above the field definitions. I
>> know the current proto isn't done that way, but let's change it - long
>> comments are good and putting them above the field definitions encourages
>> people to write enough detail without being put off by line length
>> constraints
>>
>>
>> I think the next step would be to talk to BitPay/get Jeff+Stephen involved
>> because I know they have customers that really want recurring payments, and
>> those guys will have a clearer idea of customer requirements than we do. I
>> feel uncomfortable with designing or reviewing in a vacuum without some
>> actual people who would use it chiming in, as I don't really know much about
>> the underlying business processes.
>>
>> I have some other comments about the bitcoinj implementation specifically
>> - for instance, we don't have a "wallet directory" concept: everything goes
>> into the wallet file. So we'll need to think about how to structure the code
>> to allow that. Also, just using a background polling thread is likely not
>> flexible enough, as on some platforms you can't stay running all the time
>> (e.g. Android) without upsetting people, but the underlying OS can wake you
>> up at the right times, so wallet apps should have an ability to control
>> wakeup tasks. But we can discuss that over on the bitcoinj list
>> specifically. Let's keep this thread for the general protocol design.
>>
>> BIP 70 is indeed implemented in Bitcoin Core on the C++ side, so that
>> isn't a concern. It could be done there too.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
