path: root/31/5be50c354297784bae07a00ffac7aa97154a7d

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 <mh.in.england@gmail.com>) id 1WDG8E-0001Ew-FG
	for bitcoin-development@lists.sourceforge.net;
	Tue, 11 Feb 2014 16:24:22 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
Received: from mail-ob0-f179.google.com ([209.85.214.179])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WDG8C-0000U5-J5
	for bitcoin-development@lists.sourceforge.net;
	Tue, 11 Feb 2014 16:24:22 +0000
Received: by mail-ob0-f179.google.com with SMTP id wo20so8993638obc.24
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 11 Feb 2014 08:24:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.134.166 with SMTP id pl6mr10764455oeb.16.1392135855095;
	Tue, 11 Feb 2014 08:24:15 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Tue, 11 Feb 2014 08:24:12 -0800 (PST)
Received: by 10.76.71.231 with HTTP; Tue, 11 Feb 2014 08:24:12 -0800 (PST)
In-Reply-To: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@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>
Date: Tue, 11 Feb 2014 17:24:12 +0100
X-Google-Sender-Auth: xD1ZqHN1o1pOgFrLTXhZf3XnvNE
Message-ID: <CANEZrP0Pzux7R5fJAa57JhLOn3AskD5tVSNNf9OQj7S=P3gJcw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative; boundary=047d7b41cc3e1f443004f223e31b
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1WDG8C-0000U5-J5
Cc: Bitcoin Dev <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: Tue, 11 Feb 2014 16:24:22 -0000

--047d7b41cc3e1f443004f223e31b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey guys,

I'm on vacation now so won't be able to take a look until I'm back in a
couple of weeks but the approach sounds reasonable based on your
description.
On 8 Feb 2014 08:28, "Stephane Brossier" <stephane@kill-bill.org> wrote:

> Mike and all,
>
> Pierre and I just committed a prototype implementation of the recurring
> payment protocol using bitcoinj. You can find the diff on our fork:
>
> https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116=
aa68af368a7
>
> 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 fe=
w
> 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.
>
> At a high level:
>
> 1. Creation of the subscription:
>
> The initial handshake for creating the subscription is exactly similar to
> the one for the payment protocol (PaymentRequest is used to provide the
> contract)
>
> 2. Wallet can decide to poll the merchants for its active subscriptions.
>
> 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.
>
> Please give us some feedback whenever you have the chance. In the meantim=
e
> we will start implementing the merchant side and test the code.
>
> Cheers!
>
>
>
> On Jan 31, 2014, at 10:13 AM, Mike Hearn <mike@plan99.net> wrote:
>
> 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).
>
>
>
> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <stephane@kill-bill.or=
g
> > wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From 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. Odi=
nn
>> also suggested a possible retribution for our time through crowd-sourcin=
g
>> which I am interested to pursue if that makes sense. We have quite some
>> experience on the subscription side of things and while we are growing o=
ur
>> 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 So, below is a high level description =
of
>> what we have in mind. If this sounds reasonable, we could start working =
on
>> an implementation. I. Abstract --------------- 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 serv=
ice
>> 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. 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 fo=
r
>> premium videos (overage charges). This type of billing is more complicat=
ed
>> and there are many variations to it used in the industry (pre-paid, =E2=
=80=A6). For
>> the sake of discussion, we=E2=80=99ll 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. II. Motivation ------------------ 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. Bitcoin=E2=80=99s pus=
h 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. III. Flow of
>> Operations----------------------------------------*
>>
>>
>>
>>
>> * Creation of the subscription: - - - - - - - - - - - - - - - - - - - - =
-
>> - 1. The customer clicks 'subscribe' -> A message is sent to the merchan=
t.
>> 2. The merchant sends back a message to the wallet with the details of t=
he
>> subscription such as the amount to be paid. In reality, there will be mo=
re
>> 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.
>> Ongoing payments: *
>>
>> *- - - - - - - - - - - - - - - - *
>>
>>
>>
>>
>>
>>
>> * From 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 o=
n
>> when to poll (specific dates) or not during the registration of the
>> subscription. Note that we can't simply have the wallet push X bitcoins
>> every month: the user account on the merchant side may have gotten credi=
ts,
>> invoice adjustments, etc. since the last invoice, so the amount to pay f=
or
>> a given billing period may be lower than the regular amount. It could ev=
en
>> 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 op=
ens
>> the door for the support of overage charges. 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. In that recurring phase where the wallet
>> polls the merchant, the wallet is responsible to check that payments mat=
ch
>> the subscription contract; that is, the amount, frequency of payments, =
=E2=80=A6
>> 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 wall=
et
>> and of course checks the states of the transactions on the btcnet to mar=
k
>> that payment as successful. Subscription change (optional): *
>>
>> *- - - - - - - - - - - - - - - - - - - - - - - - *
>>
>>
>> * 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 ve=
ry
>> similar to the initial registration. 1. The customer clicks 'upgrade',
>> 'downgrade', =E2=80=A6 -> A msg is sent to the merchant. 2. The merchant=
 sends back
>> a msg to the wallet with the detail of the NEW subscription. 3. The wall=
et
>> 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. Cancellation of the
>> subscription: *
>>
>> *- - - - - - - - - - - - - - - - - - - - - - - - - *
>>
>>
>>
>> * The cancellation is initiated from the customer: 1. The customer click=
s
>> 'cancel' -> The wallet is informed that it  should not accept any new
>> payment associated to that subscription. 2. The wallet sends a message t=
o
>> the merchant to inform about the cancellation. 3. The merchant confirms =
the
>> subscription was cancelled. *
>>
>
>
>

--047d7b41cc3e1f443004f223e31b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hey guys,</p>
<p dir=3D"ltr">I&#39;m on vacation now so won&#39;t be able to take a look =
until I&#39;m back in a couple of weeks but the approach sounds reasonable =
based on your description.</p>
<div class=3D"gmail_quote">On 8 Feb 2014 08:28, &quot;Stephane Brossier&quo=
t; &lt;<a href=3D"mailto:stephane@kill-bill.org">stephane@kill-bill.org</a>=
&gt; wrote:<br type=3D"attribution"><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">Mike and all,<div><br></div><div>Pierre=
 and I just committed a prototype implementation of the recurring payment p=
rotocol using bitcoinj. You can find the diff on our fork:=C2=A0</div><div>=
<a href=3D"https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539=
c60316116aa68af368a7" target=3D"_blank">https://github.com/killbill/bitcoin=
j/commit/40c657c4191498f12539c60316116aa68af368a7</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 tes=
ts). 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 sche=
me. We created a new package &#39;recurring&#39; where most of the new code=
 lives.</div>
<div><br></div><div>At a high level:</div><div><br></div><div>1. Creation o=
f the subscription:</div><div><br></div><div>The initial handshake for crea=
ting the subscription is exactly similar to the one for the payment protoco=
l (PaymentRequest is used to provide the contract)</div>
<div><br></div><div>2. Wallet can decide to poll the merchants for its acti=
ve 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 p=
ayment matches the contract and should go through.</div>
<div><br></div><div>Please give us some feedback whenever you have the chan=
ce. In the meantime we will start implementing the merchant side and test t=
he 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 hr=
ef=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt; wro=
te:</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 lev=
el 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 yo=
u prototype these things will become clearer. =C2=A0You could try prototypi=
ng either in Bitcoin Core (C++) or bitcoinj (java, look at the PaymentSessi=
on 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">st=
ephane@kill-bill.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #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-align:baseline=
;white-space:pre-wrap">From what I have seen so far, there seems to be an a=
greement that this is a nice feature to add. </span><b><div style=3D"line-h=
eight:1.15;margin-top:0pt;margin-bottom:0pt;display:inline!important">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">We are pretty new to that community a=
nd so we don&#39;t know exactly what the process is, and in particular how =
we reach consensus via email. I am certainly open to follow &#39;the way&#3=
9; if there is one, but one solution would be to follow Mike&#39;s suggesti=
on on providing a (prototype) implementation first and then defining/refini=
ng the BIP. Odinn also suggested a possible retribution for our time throug=
h 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:n=
ormal;vertical-align:baseline;white-space:pre-wrap"></span><br><span style=
=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:base=
line;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=
-align: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 B=
itcoin technology (and ecosystem at large) we would benefit from:</span></d=
iv>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">* some feedbacks on the high level proposal</sp=
an></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;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;vert=
ical-align: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-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">So, below is a high level description of what we have in mind. If this so=
unds reasonable, we could start working on an implementation.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align: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=
-align: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-space:pre-wrap">I. Abstract</spa=
n></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap">---------------</span></div><br><span style=3D"font-size:15px;font=
-family:Arial;vertical-align:baseline;white-space:pre-wrap"></span><div sty=
le=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">This describes a protocol to enable r=
ecurring 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 k=
ind (that is, agreeing on the terms of that subscription contract), and the=
n 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;vert=
ical-align: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-f=
amily:Arial;font-weight:normal;vertical-align: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. resourc=
es). Note that there is also usage based billing: for example, the user may=
 need to purchase additional access for premium videos (overage charges). T=
his type of billing is more complicated and there are many variations to it=
 used in the industry (pre-paid, =E2=80=A6). For the sake of discussion, we=
=E2=80=99ll 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;f=
ont-weight:normal;vertical-align: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-space:pre-w=
rap">II. Motivation</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap">------------------</span></div><br><span style=3D"font-size:15px;f=
ont-family:Arial;vertical-align: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=
-align: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;vert=
ical-align: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-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">Bitcoin=E2=80=99s push model presents new advantages for the customer com=
pared to traditional payment methods: the user has control over the subscri=
ption (for example, there is no need to call the merchant to explicitly can=
cel the credit card payments). It also opens the door to subscription manag=
ement 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;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align: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;whi=
te-space:pre-wrap">III. Flow of Operations</span></div>--------------------=
--------------------</b><div><b><br><span style=3D"font-size:15px;font-fami=
ly:Arial;vertical-align:baseline;white-space:pre-wrap"></span><br>

<span style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap"></span><div style=3D"line-height:1.15;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"font-size:15px;font-family:Arial;vertical-al=
ign:baseline;white-space:pre-wrap">Creation of the subscription:</span></di=
v>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-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-b=
ottom:0pt">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">1. The customer clicks &#39;subscribe=
&#39; -&gt; A message is sent to the merchant.</span></div><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align: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 th=
e prototype implementation this is sufficient.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The wallet prompts the customer for authoriz=
ation.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">4. The customer authorizes (or denies) it.</spa=
n></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">5. The wallet sends the confirmation to the mer=
chant.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">6. The merchant confirms the subscription was c=
reated.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align: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-f=
amily:Arial;vertical-align:baseline;white-space: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;w=
hite-space:pre-wrap">- - - - - - - - - - - - - - - -</span></div>
<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b></div><b><span style=3D"font-size:15px;font-f=
amily:Arial;vertical-align: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=
-align:baseline;white-space:pre-wrap">From that time on and since Bitcoin i=
s a &#39;push&#39; model, the wallet is responsible to poll the merchant fo=
r due payments associated with that subscription. Note that the merchant co=
uld specify hints to the wallet on when to poll (specific dates) or not dur=
ing the registration of the subscription.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align: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-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">Note that we can&#39;t simply have the wallet push X bitcoins every month=
: the user account on the merchant side may have gotten credits, invoice ad=
justments, etc. since the last invoice, so the amount to pay for a given bi=
lling 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 bala=
nce to make sure how much it should pay. This also opens the door for the s=
upport of overage charges.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align: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=
-align:baseline;white-space:pre-wrap">Quick note on the implementation on t=
he 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 ac=
count status (unpaid invoices, etc.). This goes often hand in hand with a d=
unning system, which progressively restricts access as the user&#39;s accou=
nt is more and more overdue. Since wallets can be offline for an extended p=
eriod of time, payments may be missed and lead to an overdue state (e.g. ex=
tra fees, service degraded). It is the responsibility of the customer to en=
sure 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;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align: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=
-align:baseline;white-space:pre-wrap">In that recurring phase where the wal=
let polls the merchant, the wallet is responsible to check that payments ma=
tch the subscription contract; that is, the amount, frequency of payments, =
=E2=80=A6 match what the customer agreed on. If so, the payment is made wit=
hout 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 transact=
ion is sent to the btcnet. The merchant sends an ACK to the wallet and of c=
ourse checks the states of the transactions on the btcnet to mark that paym=
ent as successful.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align: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-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap">Subscription chan=
ge (optional):</span></div>

</b><b><div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-=
space:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - </span></di=
v>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b><b><span style=3D"font-size:15px;font-family:=
Arial;vertical-align:baseline;white-space:pre-wrap"></span><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">Optionally we could implement a chang=
e in the ongoing subscription to address the upgrade/downgrade scenarios. O=
f course, we could also simply support a cancellation followed by a creatio=
n of a new subscription, but having that as a one atomic message is probabl=
y better. The steps are very similar to the initial registration.</span></d=
iv>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align: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-f=
amily:Arial;font-weight:normal;vertical-align:baseline;white-space:pre-wrap=
">1. The customer clicks &#39;upgrade&#39;, &#39;downgrade&#39;, =E2=80=A6 =
-&gt; A msg is sent to the merchant.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;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 styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The wallet prompts the customer for authoriz=
ation.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">4. The customer authorizes (or denies) it.</spa=
n></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">5. The wallet sends the confirmation to the mer=
chant.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">6. The merchant confirms the change in the subs=
cription.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align: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-f=
amily:Arial;vertical-align:baseline;white-space:pre-wrap">Cancellation of t=
he subscription:</span></div>

</b><b><div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-=
space:pre-wrap">- - - - - - - - - - - - - - - - - - - - - - - - - </span></=
div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;vertical-align:baseline;white-space:p=
re-wrap"><br></span></div></b><b><span style=3D"font-size:15px;font-family:=
Arial;vertical-align:baseline;white-space:pre-wrap"></span><div style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt">

<span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical=
-align:baseline;white-space:pre-wrap">The cancellation is initiated from th=
e customer:</span></div><br><span style=3D"font-size:15px;font-family:Arial=
;font-weight:normal;vertical-align:baseline;white-space:pre-wrap"></span><d=
iv 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=
-align:baseline;white-space:pre-wrap">1. The customer clicks &#39;cancel&#3=
9; -&gt; The wallet is informed that it =C2=A0should not accept any new pay=
ment associated to that subscription.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">2. The wallet sends a message to the merchant t=
o inform about the cancellation.</span></div>

<div style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span styl=
e=3D"font-size:15px;font-family:Arial;font-weight:normal;vertical-align:bas=
eline;white-space:pre-wrap">3. The merchant confirms the subscription was c=
ancelled.</span></div>

<br><span style=3D"font-size:15px;font-family:Arial;font-weight:normal;vert=
ical-align:baseline;white-space:pre-wrap"></span><br><span style=3D"font-si=
ze:15px;font-family:Arial;font-weight:normal;vertical-align:baseline;white-=
space:pre-wrap"></span></b></div>

</div></blockquote></div><br></div>
</blockquote></div><br></div></div></blockquote></div>

--047d7b41cc3e1f443004f223e31b--