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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephane@kill-bill.org>) id 1WCKXu-0003XI-I4
for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 02:55:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of kill-bill.org
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=stephane@kill-bill.org;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WCKXp-0008MD-Ec
for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 02:55:00 +0000
Received: by mail-pb0-f47.google.com with SMTP id rp16so4852676pbb.20
for <bitcoin-development@lists.sourceforge.net>;
Sat, 08 Feb 2014 18:54:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:content-type:mime-version:subject:from
:in-reply-to:date:cc:message-id:references:to;
bh=D56XjfiZYp1Erl8tjhwDIux5+4pcbNdHTmFpiTf/s2o=;
b=mXtMDQWId/TrWTSduM6UiHs4xctgU0vc1PvwL9ygGvNURMUWoeV8XxanapyTDrijV6
e0muvz8F+Yp/w1sTqAX+SIsNUMVu34kKxZj+ThZo3ry+5Zw61+UMXige99HRR2ebQNgP
W7CTD553e6VrRXWtrg3x8sO9yOw79PxGQZnWH0ICKsG+pKF0Hy2h9x8XHOHI9cROcihN
A80xhT6ftsBV0rHsh52n3VNAIpDp4/nIv/PxBDuYWLjtTInETiv3lsZjinpy3F2DlBSo
wwdiF7qU2vxpWjJBi5QCAsVbJ+ROc3r4ow6NeBPSqGHfxFWMHN9U3HbsbfsZQ8HmtGds
viqw==
X-Gm-Message-State: ALoCoQksb5p0VAhLSpObZ34+PzL3SSRhfNP2FvEo+gL897d6ILNwsvhhO7RDl6enw+M1UAioCM6J
X-Received: by 10.66.193.202 with SMTP id hq10mr17292399pac.57.1391914088977;
Sat, 08 Feb 2014 18:48:08 -0800 (PST)
Received: from [192.168.1.104] (adsl-71-146-11-192.dsl.pltn13.sbcglobal.net.
[71.146.11.192]) by mx.google.com with ESMTPSA id
si6sm73411800pab.19.2014.02.08.18.48.06 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 08 Feb 2014 18:48:08 -0800 (PST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Stephane Brossier <stephane@kill-bill.org>
In-Reply-To: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org>
Date: Sat, 8 Feb 2014 18:48:06 -0800
Message-Id: <DBA255DB-4839-4C3A-BA62-BD3926995C12@kill-bill.org>
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>
To: Mike Hearn <mike@plan99.net>,
gavinandresen@gmail.com
X-Mailer: Apple Mail (2.1510)
X-Spam-Score: -0.5 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WCKXp-0008MD-Ec
Cc: bitcoin-development@lists.sourceforge.net,
Pierre-Alexandre Meyer <pierre@kill-bill.org>
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: Sun, 09 Feb 2014 02:55:02 -0000
--Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Mike, Gavin,
We started to work on the merchant side to test the integration of our =
prototype for the recurring payments. We modified the 'Payment Request =
Generator' from Gavin to include a new check box 'set recurring'. We =
forked the code and checked in our modification here: =
https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7=
c3154ad39267c3f3
We also found a few issues with the code diff that we sent yesterday for =
bitcoinj and checked in the bug fixes in our fork-- so the diff sent =
yesterday is slightly outdated.
So at this point we have a working prototype for bitcoinj and we are =
waiting for your feedbacks. We also started to look at integrating the =
protocol in Kill Bill to check that what is proposed supports indeed the =
business cases of a full recurring billing platform.
Hope to hear from you guys soon!
On Feb 7, 2014, at 6:57 PM, Stephane Brossier <stephane@kill-bill.org> =
wrote:
> Mike and all,
>=20
> Pierre and I just committed a prototype implementation of the =
recurring payment protocol using bitcoinj. You can find the diff on our =
fork:=20
> =
https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116a=
a68af368a7
>=20
> We did not write the server (merchant side), but wanted to have some =
feedback before going deeper (merchant implementation and tests). We did =
our best to build it on top of the existing BIP-0070 protocol-- only a =
few additions in the messages, but no new calls and no new uri scheme. =
We created a new package 'recurring' where most of the new code lives.
>=20
> At a high level:
>=20
> 1. Creation of the subscription:
>=20
> The initial handshake for creating the subscription is exactly similar =
to the one for the payment protocol (PaymentRequest is used to provide =
the contract)
>=20
> 2. Wallet can decide to poll the merchants for its active =
subscriptions.
>=20
> Here the flow is exactly similar to the payment protocol but the =
wallet receives a callback to verify the payment matches the contract =
and should go through.
>=20
> Please give us some feedback whenever you have the chance. In the =
meantime we will start implementing the merchant side and test the code.
>=20
> Cheers!
>=20
>=20
>=20
> On Jan 31, 2014, at 10:13 AM, Mike Hearn <mike@plan99.net> wrote:
>=20
>> That looks OK at a very high level. Things you probably want to think =
about:
>> How to trigger it off the existing payment protocol (no new top level =
messages or mime types or uri extensions please)
>> Data structures to define the payment schedule
>> Do you allow pre-submission of time locked transactions or not?
>> I think as you prototype these things will become clearer. You could =
try prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at =
the PaymentSession class).
>>=20
>>=20
>>=20
>> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier =
<stephane@kill-bill.org> wrote:
>> =46rom what I have seen so far, there seems to be an agreement that =
this is a nice feature to add. We are pretty new to that community and =
so we don't know exactly what the process is, and in particular how we =
reach consensus via email. I am certainly open to follow 'the way' if =
there is one, but one solution would be to follow Mike's suggestion on =
providing a (prototype) implementation first and then defining/refining =
the BIP. Odinn also suggested a possible retribution for our time =
through crowd-sourcing which I am interested to pursue if that makes =
sense.
>>=20
>>=20
>> We have quite some experience on the subscription side of things and =
while we are growing our knowledge on the Bitcoin technology (and =
ecosystem at large) we would benefit from:
>> * some feedbacks on the high level proposal
>> * additional requirements we might have missed
>>=20
>> So, below is a high level description of what we have in mind. If =
this sounds reasonable, we could start working on an implementation.
>>=20
>>=20
>> =20
>> I. Abstract
>> ---------------
>>=20
>> This describes a protocol to enable recurring payments in bitcoins =
and can be seen as an extension of BIP-0070. The main goal here is to =
have the customer subscribe to a service of some kind (that is, agreeing =
on the terms of that subscription contract), and then have the wallet =
make recurring payments without any intervention from the customer as =
long as the payments match what the customer agreed on paying.
>>=20
>> An example of such service would be an online streaming website, to =
which a user pays a fixed recurring monthly fee to access videos (a.k.a. =
resources). Note that there is also usage based billing: for example, =
the user may need to purchase additional access for premium videos =
(overage charges). This type of billing is more complicated and there =
are many variations to it used in the industry (pre-paid, =85). For the =
sake of discussion, we=92ll focus on fixed recurring payments only, but =
we will keep usage in mind to make sure the protocol will be able to =
support it as well.
>>=20
>>=20
>> II. Motivation
>> ------------------
>>=20
>> Subscription based services have been growing in the past few years =
and so the intent it to make it possible for customers to pay in =
bitcoins.=20
>>=20
>> Bitcoin=92s push model presents new advantages for the customer =
compared to traditional payment methods: the user has control over the =
subscription (for example, there is no need to call the merchant to =
explicitly cancel the credit card payments). It also opens the door to =
subscription management tools in wallets (e.g. Hive apps), which would =
give user an overview of what they are paying each month.
>>=20
>>=20
>> III. Flow of Operations
>> ----------------------------------------
>>=20
>>=20
>> Creation of the subscription:
>> - - - - - - - - - - - - - - - - - - - - - -=20
>>=20
>> 1. The customer clicks 'subscribe' -> A message is sent to the =
merchant.
>> 2. The merchant sends back a message to the wallet with the details =
of the subscription such as the amount to be paid. In reality, there =
will be more information but for the purpose of the prototype =
implementation this is sufficient.
>> 3. The wallet prompts the customer for authorization.
>> 4. The customer authorizes (or denies) it.
>> 5. The wallet sends the confirmation to the merchant.
>> 6. The merchant confirms the subscription was created.
>>=20
>> Ongoing payments:
>> - - - - - - - - - - - - - - - -
>>=20
>> =46rom that time on and since Bitcoin is a 'push' model, the wallet =
is responsible to poll the merchant for due payments associated with =
that subscription. Note that the merchant could specify hints to the =
wallet on when to poll (specific dates) or not during the registration =
of the subscription.
>>=20
>> Note that we can't simply have the wallet push X bitcoins every =
month: the user account on the merchant side may have gotten credits, =
invoice adjustments, etc. since the last invoice, so the amount to pay =
for a given billing period may be lower than the regular amount. It =
could even be zero if the user decides to make a one-time payment to the =
merchant directly using a different wallet. Hence, the wallet needs to =
get the latest invoice balance to make sure how much it should pay. This =
also opens the door for the support of overage charges.
>>=20
>>=20
>> Quick note on the implementation on the merchant side: an entitlement =
system is a piece of logic on the merchant side which grants the user =
access to certain resources depending on the account status (unpaid =
invoices, etc.). This goes often hand in hand with a dunning system, =
which progressively restricts access as the user's account is more and =
more overdue. Since wallets can be offline for an extended period of =
time, payments may be missed and lead to an overdue state (e.g. extra =
fees, service degraded). It is the responsibility of the customer to =
ensure the wallet is up often enough for payments to happen.
>>=20
>>=20
>> In that recurring phase where the wallet polls the merchant, the =
wallet is responsible to check that payments match the subscription =
contract; that is, the amount, frequency of payments, =85 match what the =
customer agreed on. If so, the payment is made without asking for =
explicit approval from customer, and the flow is similar to BIP-0070: =
The message is sent to the merchant, and in parallel, a transaction is =
sent to the btcnet. The merchant sends an ACK to the wallet and of =
course checks the states of the transactions on the btcnet to mark that =
payment as successful.
>>=20
>> Subscription change (optional):
>> - - - - - - - - - - - - - - - - - - - - - - - -=20
>>=20
>> Optionally we could implement a change in the ongoing subscription to =
address the upgrade/downgrade scenarios. Of course, we could also simply =
support a cancellation followed by a creation of a new subscription, but =
having that as a one atomic message is probably better. The steps are =
very similar to the initial registration.
>>=20
>> 1. The customer clicks 'upgrade', 'downgrade', =85 -> A msg is sent =
to the merchant.
>> 2. The merchant sends back a msg to the wallet with the detail of the =
NEW subscription.=20
>> 3. The wallet prompts the customer for authorization.
>> 4. The customer authorizes (or denies) it.
>> 5. The wallet sends the confirmation to the merchant.
>> 6. The merchant confirms the change in the subscription.
>>=20
>> Cancellation of the subscription:
>> - - - - - - - - - - - - - - - - - - - - - - - - -=20
>>=20
>> The cancellation is initiated from the customer:
>>=20
>> 1. The customer clicks 'cancel' -> The wallet is informed that it =
should not accept any new payment associated to that subscription.
>> 2. The wallet sends a message to the merchant to inform about the =
cancellation.
>> 3. The merchant confirms the subscription was cancelled.
>>=20
>>=20
>>=20
>=20
--Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Mike, Gavin,</div><div><br></div><div><br></div><div>We started =
to work on the merchant side to test the integration of our prototype =
for the recurring payments. We modified the 'Payment Request Generator' =
from Gavin to include a new check box 'set recurring'. We forked the =
code and checked in our modification here: <a =
href=3D"https://github.com/killbill/paymentrequest/commit/e530f6ec528266aa=
cfd076d7c3154ad39267c3f3">https://github.com/killbill/paymentrequest/commi=
t/e530f6ec528266aacfd076d7c3154ad39267c3f3</a></div><div><br></div><div>We=
also found a few issues with the code diff that we sent yesterday for =
bitcoinj and checked in the bug fixes in our fork-- so the diff =
sent yesterday is slightly outdated.</div><div><br></div><div>So at this =
point we have a working prototype for bitcoinj and we are waiting for =
your feedbacks. We also started to look at integrating the protocol in =
Kill Bill to check that what is proposed supports indeed the business =
cases of a full recurring billing =
platform.</div><div><br></div><div>Hope to hear from you guys =
soon!</div><div><br></div><br><div><div>On Feb 7, 2014, at 6:57 PM, =
Stephane Brossier <<a =
href=3D"mailto:stephane@kill-bill.org">stephane@kill-bill.org</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Mike =
and all,<div><br></div><div>Pierre and I just committed a prototype =
implementation of the recurring payment protocol using bitcoinj. You can =
find the diff on our fork: </div><div><a =
href=3D"https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c6=
0316116aa68af368a7">https://github.com/killbill/bitcoinj/commit/40c657c419=
1498f12539c60316116aa68af368a7</a></div><div><br></div><div>We did not =
write the server (merchant side), but wanted to have some feedback =
before going deeper (merchant implementation and tests). We did our best =
to build it on top of the existing BIP-0070 protocol-- only a few =
additions in the messages, but no new calls and no new uri scheme. We =
created a new package 'recurring' where most of the new code =
lives.</div><div><br></div><div>At a high =
level:</div><div><br></div><div>1. Creation of the =
subscription:</div><div><br></div><div>The initial handshake for =
creating the subscription is exactly similar to the one for the payment =
protocol (PaymentRequest is used to provide the =
contract)</div><div><br></div><div>2. Wallet can decide to poll the =
merchants for its active subscriptions.</div><div><br></div><div>Here =
the flow is exactly similar to the payment protocol but the wallet =
receives a callback to verify the payment matches the contract and =
should go through.</div><div><br></div><div>Please give us some feedback =
whenever you have the chance. In the meantime we will start implementing =
the merchant side and test the =
code.</div><div><br></div><div>Cheers!</div><div><br></div><div><br></div>=
<div><br><div><div>On Jan 31, 2014, at 10:13 AM, Mike Hearn <<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr">That looks OK at a very high level. Things you probably want =
to think about:<div><ul><li>How to trigger it off the existing payment =
protocol (no new top level messages or mime types or uri extensions =
please)</li>
<li>Data structures to define the payment schedule</li><li>Do you allow =
pre-submission of time locked transactions or not?</li></ul><div>I think =
as you prototype these things will become clearer. You could try =
prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the =
PaymentSession class).</div>
</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier =
<span dir=3D"ltr"><<a href=3D"mailto:stephane@kill-bill.org" =
target=3D"_blank">stephane@kill-bill.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">=46rom what I have seen so far, there =
seems to be an agreement that this is a nice feature to add. =
</span><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;display:inline!=
important">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">We are pretty new to that community and =
so we don't know exactly what the process is, and in particular how we =
reach consensus via email. I am certainly open to follow 'the way' if =
there is one, but one solution would be to follow Mike's suggestion on =
providing a (prototype) implementation first and then defining/refining =
the BIP. Odinn also suggested a possible retribution for our time =
through crowd-sourcing which I am interested to pursue if that makes =
sense.</span></div>
</b></div><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">We have quite some experience on the =
subscription side of things and while we are growing our knowledge on =
the Bitcoin technology (and ecosystem at large) we would benefit =
from:</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">* some feedbacks on the high level =
proposal</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">* additional requirements we might have =
missed</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">So, below is a high level description =
of what we have in mind. If this sounds reasonable, we could start =
working on an implementation.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><p dir=3D"ltr" =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"> </span></p><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">I. Abstract</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">---------------</span></div><br><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">This describes a protocol to enable =
recurring payments in bitcoins and can be seen as an extension of =
BIP-0070. The main goal here is to have the customer subscribe to a =
service of some kind (that is, agreeing on the terms of that =
subscription contract), and then have the wallet make recurring payments =
without any intervention from the customer as long as the payments match =
what the customer agreed on paying.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">An example of such service would be an =
online streaming website, to which a user pays a fixed recurring monthly =
fee to access videos (a.k.a. resources). Note that there is also usage =
based billing: for example, the user may need to purchase additional =
access for premium videos (overage charges). This type of billing is =
more complicated and there are many variations to it used in the =
industry (pre-paid, =85). For the sake of discussion, we=92ll focus on =
fixed recurring payments only, but we will keep usage in mind to make =
sure the protocol will be able to support it as well.</span></div>
<div><b><br></b></div><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">II. Motivation</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">------------------</span></div><br><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">Subscription based services have been =
growing in the past few years and so the intent it to make it possible =
for customers to pay in bitcoins. </span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">Bitcoin=92s push model presents new =
advantages for the customer compared to traditional payment methods: the =
user has control over the subscription (for example, there is no need to =
call the merchant to explicitly cancel the credit card payments). It =
also opens the door to subscription management tools in wallets (e.g. =
Hive apps), which would give user an overview of what they are paying =
each month.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">III. Flow of =
Operations</span></div>----------------------------------------</b><div><b=
><br><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><br>
<span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">Creation of the subscription:</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - =
</span></div><br><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">1. The customer clicks 'subscribe' =
-> A message is sent to the merchant.</span></div><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">2. The merchant sends back a message to =
the wallet with the details of the subscription such as the amount to be =
paid. In reality, there will be more information but for the purpose of =
the prototype implementation this is sufficient.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">3. The wallet prompts the customer for =
authorization.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">4. The customer authorizes (or denies) =
it.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">5. The wallet sends the confirmation to =
the merchant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">6. The merchant confirms the =
subscription was created.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">Ongoing payments:</span></div>
</b><div class=3D"im"><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">- - - - - - - - - - - - - - - -</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"><br></span></div></b></div><b><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">=46rom that time on and since Bitcoin =
is a 'push' model, the wallet is responsible to poll the merchant for =
due payments associated with that subscription. Note that the merchant =
could specify hints to the wallet on when to poll (specific dates) or =
not during the registration of the subscription.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">Note that we can't simply have the =
wallet push X bitcoins every month: the user account on the merchant =
side may have gotten credits, invoice adjustments, etc. since the last =
invoice, so the amount to pay for a given billing period may be lower =
than the regular amount. It could even be zero if the user decides to =
make a one-time payment to the merchant directly using a different =
wallet. Hence, the wallet needs to get the latest invoice balance to =
make sure how much it should pay. This also opens the door for the =
support of overage charges.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">Quick note on the implementation on the =
merchant side: an entitlement system is a piece of logic on the merchant =
side which grants the user access to certain resources depending on the =
account status (unpaid invoices, etc.). This goes often hand in hand =
with a dunning system, which progressively restricts access as the =
user's account is more and more overdue. Since wallets can be offline =
for an extended period of time, payments may be missed and lead to an =
overdue state (e.g. extra fees, service degraded). It is the =
responsibility of the customer to ensure the wallet is up often enough =
for payments to happen.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">In that recurring phase where the =
wallet polls the merchant, the wallet is responsible to check that =
payments match the subscription contract; that is, the amount, frequency =
of payments, =85 match what the customer agreed on. If so, the payment =
is made without asking for explicit approval from customer, and the flow =
is similar to BIP-0070: The message is sent to the merchant, and in =
parallel, a transaction is sent to the btcnet. The merchant sends an ACK =
to the wallet and of course checks the states of the transactions on the =
btcnet to mark that payment as successful.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">Subscription change (optional):</span></div>
</b><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - =
</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"><br></span></div></b><b><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">Optionally we could implement a change =
in the ongoing subscription to address the upgrade/downgrade scenarios. =
Of course, we could also simply support a cancellation followed by a =
creation of a new subscription, but having that as a one atomic message =
is probably better. The steps are very similar to the initial =
registration.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">1. The customer clicks 'upgrade', =
'downgrade', =85 -> A msg is sent to the merchant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">2. The merchant sends back a msg to the =
wallet with the detail of the NEW subscription. </span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">3. The wallet prompts the customer for =
authorization.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">4. The customer authorizes (or denies) =
it.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">5. The wallet sends the confirmation to =
the merchant.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">6. The merchant confirms the change in =
the subscription.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">Cancellation of the subscription:</span></div>
</b><b><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - - =
</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"><br></span></div></b><b><span =
style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-sp=
ace:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">The cancellation is initiated from the =
customer:</span></div><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><div =
style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">
<span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">1. The customer clicks 'cancel' -> =
The wallet is informed that it should not accept any new payment =
associated to that subscription.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">2. The wallet sends a message to the =
merchant to inform about the cancellation.</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap">3. The merchant confirms the =
subscription was cancelled.</span></div>
<br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span><br><span =
style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-alig=
n:baseline;white-space:pre-wrap"></span></b></div>
</div></blockquote></div><br></div>
</blockquote></div><br></div></div></blockquote></div><br></body></html>=
--Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527--
|