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; 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F4CCAE89-162A-40E6-A70C-751F5135609A"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Stephane Brossier <stephane@kill-bill.org>
In-Reply-To: <CAEY8wq6F33814d2+97AqDoAicvh=0PigHZ03wHadMq6JqtQMLg@mail.gmail.com>
Date: Tue, 11 Feb 2014 10:01:23 -0800
Message-Id: <EAEC76DA-A490-4A61-BFB7-611D4ADF1680@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>
	<DBA255DB-4839-4C3A-BA62-BD3926995C12@kill-bill.org>
	<CAEY8wq6F33814d2+97AqDoAicvh=0PigHZ03wHadMq6JqtQMLg@mail.gmail.com>
To: Kevin Greene <kgreenek@gmail.com>
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
Precedence: list


--Apple-Mail=_F4CCAE89-162A-40E6-A70C-751F5135609A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Kevin,

On Feb 11, 2014, at 2:00 AM, Kevin Greene <kgreenek@gmail.com> wrote:

> Figured I would have a crack at reviewing this since Mike is out for a =
bit. It was great running into you guys at the bitcoin fair in SF! Small =
world :)

Indeed! It was great meeting you! It's always nice to meet people in =
person...

> I like how simple this is. You just give it an url to fetch the next =
payment request and a date to fetch it.
>=20
> What should happen if the client tries to fetch the PaymentRequest =
early or late?

If the client tries to fetch too early, then  the merchant will return a =
PaymentRequest with no output (there is nothing to pay yet). If it =
fetches too late, this is merchant specific. It could be that the =
service got discontinued -- extreme case -- or that there are now =
multiple PaymentRequest pending or that the merchant decided to =
aggregate those into one. In that scenario, it could lead to a case =
where the amount to pay goes beyond the contract and the wallet would =
refuse to make the recurring payment.

> Does it become valid after some date and stay valid for some length of =
time?

The protocol we sketched does not include (yet) an expiration date. At =
this point the contract is fairly minimal, and we could envision adding =
more parameters such as expiration date. So at this point the behavior =
would be dictated by the merchant.

> Also, what should happen if the client tries to consume the same =
PaymentRequest twice (or multiple times) during the same period?

The merchant initiates the PaymentRequest and is in charge to make sure =
they match the invoices that the client should pay. On the client side, =
the wallet is responsible to verify that the contract is respected, so =
if a merchant were to issue multiple times the same PaymentRequest, the =
wallet would detect it goes beyond the bonds defined in the contract and =
would refuse to make the additional Payments.

> I do not think daily/weekly/monthly is flexible enough. What do you =
think about having a concrete start time and end time when the next =
PaymentRequest will be valid?

I agree that daily/weekly/monthly may not be flexible enough. However =
specifying a fixed date may be very tricky because in some cases a =
monthly subscription may start on a 31st of a month, and depending on =
the month, the due date will vary -- could be 30th, 28th, 29th, ... Also =
note that the frequency (daily/weekly/monthly) is not used as a polling =
interval, but is only used to verify the contract is respected.=20

There are multiple viable options to specify that contract and ideally =
we could/should support multiple schemes; different merchants could use =
different schemes, and the client would decide wether or not he is ready =
to accept the terms that will later be enforced by the wallet. But of =
course all this flexibility goes against simplicity and so this is =
tradeoff...


> This also prevents the wallet from having to remember when it last =
sent a payment and getting skewed over time.

Today, our current prototype is polling every day -- which is the lowest =
granularity we introduced -- and so there is no risk of getting skewed.


> When a wallet hits the polling_url to download the next =
PaymentRequest, it seems we need a way to communicate an error code to =
the wallet, for example if the server canceled the contract without the =
wallet knowing. Perhaps a separate polling_status_url, with a =
corresponding ACK message to indicate if the PaymentRequest is =
available. What do you think of that idea?

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?

> One high-level comment -- the wallet in this design doesn't have any =
way of knowing when the payments are supposed to end. I feel this is =
important to show to the user before they start their wallet polling =
infinitely.

Subscriptions are non ending by definition, but at any time the client =
(through the wallet) or the merchant can decide to terminate the =
subscriptions -- we did not yet implement cancellation in that prototype =
but we are planning to add it later this week. Think of your Netflix =
subscriptions, this is never ending (evergreen) until you decide to =
terminate it or Netflix does it (abuse, bills not paid,...)

Thanks for taking a look!

>=20
> On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier =
<stephane@kill-bill.org> wrote:
> Mike, Gavin,
>=20
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> Hope to hear from you guys soon!
>=20
>=20
> On Feb 7, 2014, at 6:57 PM, Stephane Brossier <stephane@kill-bill.org> =
wrote:
>=20
>> 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
>=20
>=20


--Apple-Mail=_F4CCAE89-162A-40E6-A70C-751F5135609A
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; ">Hi =
Kevin,<div><br><div><div>On Feb 11, 2014, at 2:00 AM, Kevin Greene =
&lt;<a href=3D"mailto:kgreenek@gmail.com">kgreenek@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"color:rgb(51,102,102)">Figured I would have a crack at =
reviewing this since Mike is out for a bit. It was great running into =
you guys at the bitcoin fair in SF! Small world =
:)</div></div></blockquote><div><br></div><div>Indeed! It was great =
meeting you! It's always nice to meet people in =
person...</div></div><div><br><blockquote type=3D"cite"><div dir=3D"ltr">

<div class=3D"gmail_default" style=3D"color:rgb(51,102,102)">I like how =
simple this is. You just give it an url to fetch the next payment =
request and a date to fetch it.</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)">What should happen if the client tries =
to fetch the PaymentRequest early or =
late?</div></div></blockquote><div><br></div><div>If the client tries to =
fetch too early, then &nbsp;the merchant will return a PaymentRequest =
with no output (there is nothing to pay yet). If it fetches too late, =
this is merchant specific. It could be that the service got discontinued =
-- extreme case -- or that there are now multiple PaymentRequest pending =
or that the merchant decided to aggregate those into one. In that =
scenario, it could lead to a case where the amount to pay goes beyond =
the contract and the wallet would refuse to make the recurring =
payment.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_default" style=3D"color:rgb(51,102,102)"> Does it become =
valid after some date and stay valid for some length of time? =
</div></div></blockquote><div><br></div><div>The protocol we sketched =
does not include (yet) an expiration date. At this point the contract is =
fairly minimal, and we could envision adding more parameters such as =
expiration date. So at this point the behavior would be dictated by the =
merchant.</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"color:rgb(51,102,102)">Also, what should happen if the client =
tries to consume the same PaymentRequest twice (or multiple times) =
during the same period?</div></div></blockquote><div><br></div>The =
merchant initiates the PaymentRequest and is in charge to make sure they =
match the invoices that the client should pay. On the client side, the =
wallet is responsible to verify that the contract is respected, so if a =
merchant were to issue multiple times the same PaymentRequest, the =
wallet would detect it goes beyond the bonds defined in the contract and =
would refuse to make the additional Payments.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"color:rgb(51,102,102)">I do not think daily/weekly/monthly is =
flexible enough. What do you think about having a concrete start time =
and end time when the next PaymentRequest will be =
valid?</div></div></blockquote><div><br></div>I agree that =
daily/weekly/monthly may not be flexible enough. However specifying a =
fixed date may be very tricky because in some cases a monthly =
subscription may start on a 31st of a month, and depending on the month, =
the due date will vary -- could be 30th, 28th, 29th, ... Also note that =
the frequency (daily/weekly/monthly) is not used as a polling interval, =
but is only used to verify the contract is =
respected.&nbsp;</div><div><br></div><div>There are multiple viable =
options to specify that contract and ideally we could/should support =
multiple schemes; different merchants could use different schemes, and =
the client would decide wether or not he is ready to accept the terms =
that will later be enforced by the wallet. But of course all this =
flexibility goes against simplicity and so this is =
tradeoff...</div><div><br></div><div><br></div><div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"color:rgb(51,102,102)"> This also prevents the wallet from =
having to remember when it last sent a payment and getting skewed over =
time.</div></div></blockquote><div><br></div><div>Today, our current =
prototype is polling every day -- which is the lowest granularity we =
introduced -- and so there is no risk of getting =
skewed.</div><div><br></div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"color:rgb(51,102,102)">When a wallet hits the polling_url to =
download the next PaymentRequest, it seems we need a way to communicate =
an error code to the wallet, for example if the server canceled the =
contract without the wallet knowing. Perhaps a separate =
polling_status_url, with a corresponding ACK message to indicate if the =
PaymentRequest is available. What do you think of that =
idea?</div></div></blockquote><div><br></div>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?</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr">

<div class=3D"gmail_default" style=3D"color:rgb(51,102,102)">One =
high-level comment -- the wallet in this design doesn't have any way of =
knowing when the payments are supposed to end. I feel this is important =
to show to the user before they start their wallet polling =
infinitely.</div></div></blockquote><div><br></div>Subscriptions are non =
ending by definition, but at any time the client (through the wallet) or =
the merchant can decide to terminate the subscriptions -- we did not yet =
implement cancellation in that prototype but we are planning to add it =
later this week. Think of your Netflix subscriptions, this is never =
ending (evergreen) until you decide to terminate it or Netflix does it =
(abuse, bills not paid,...)</div><div><br></div><div>Thanks for taking a =
look!</div><div><br><blockquote type=3D"cite"><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Feb 8, 2014 =
at 6:48 PM, Stephane Brossier <span dir=3D"ltr">&lt;<a =
href=3D"mailto:stephane@kill-bill.org" =
target=3D"_blank">stephane@kill-bill.org</a>&gt;</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"><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:&nbsp;<a =
href=3D"https://github.com/killbill/paymentrequest/commit/e530f6ec528266aa=
cfd076d7c3154ad39267c3f3" =
target=3D"_blank">https://github.com/killbill/paymentrequest/commit/e530f6=
ec528266aacfd076d7c3154ad39267c3f3</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 &nbsp;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><div =
class=3D"h5"><div><br></div><br><div><div>On Feb 7, 2014, at 6:57 PM, =
Stephane Brossier &lt;<a href=3D"mailto:stephane@kill-bill.org" =
target=3D"_blank">stephane@kill-bill.org</a>&gt; wrote:</div>

<br><blockquote type=3D"cite"><div style=3D"word-wrap:break-word">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:&nbsp;</div>

<div><a =
href=3D"https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c6=
0316116aa68af368a7" =
target=3D"_blank">https://github.com/killbill/bitcoinj/commit/40c657c41914=
98f12539c60316116aa68af368a7</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 &lt;<a =
href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt; =
wrote:</div><br><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. &nbsp;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">&lt;<a href=3D"mailto:stephane@kill-bill.org" =
target=3D"_blank">stephane@kill-bill.org</a>&gt;</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' =
-&gt; 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><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 -&gt; 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' -&gt; =
The wallet is informed that it &nbsp;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></div></div></di=
v></blockquote></div><br></div>
</blockquote></div><br></div></body></html>=

--Apple-Mail=_F4CCAE89-162A-40E6-A70C-751F5135609A--