path: root/c8/4066b432cea51c37723ac1e32f3696a59e8e66

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephane@kill-bill.org>) id 1WBy76-00028Z-6T
	for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Feb 2014 02:57:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of kill-bill.org
	designates 209.85.160.43 as permitted sender)
	client-ip=209.85.160.43; envelope-from=stephane@kill-bill.org;
	helo=mail-pb0-f43.google.com; 
Received: from mail-pb0-f43.google.com ([209.85.160.43])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WBy74-0006AU-7m
	for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Feb 2014 02:57:52 +0000
Received: by mail-pb0-f43.google.com with SMTP id md12so4017569pbc.16
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 07 Feb 2014 18:57:44 -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=6g7u677B9Uwcc9WDYY2ALYaCzFyHG0Py3NVBf80eFI0=;
	b=Tbx60RVzUPLUpP83A80s9t4HMKx/EDjZjF3rgK9yjYGnTQqLCHYD0EZFkIf2oIclqB
	NrxFT3vdIS7ny8cDIkEk1rxrFZFifMKL16bHGqcJARFLsQtSv20QIxriR209h9nkcnGR
	R+lD1iMqIk4rb7ytebr4lbdzIoLUyNwlPDpN1NMPHpl+0EP1BSP0kErqsPhFbkc6v3Yg
	GNLYxWFf+DZCXcFkS8SP5+HhDX3oFVWkZ/ymO57GSYOjTTdFio5pdej3+AfwPStfwboB
	iEnXVXrVqWjJ+GDb6KwC2e0eyqU0C0eQD9tmzHHTe3I093YjBgoTXVYgTIa2/lHxmMfR
	wa3Q==
X-Gm-Message-State: ALoCoQnVIarJJfIFfKesNNhRWaX5zyV6QDN8GqNCP7UISr8UFB4q8PE6yHG1qyM8/Fic/xprHV+j
X-Received: by 10.68.178.197 with SMTP id da5mr23702477pbc.28.1391828264294;
	Fri, 07 Feb 2014 18:57:44 -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
	vg1sm18458135pbc.44.2014.02.07.18.57.42 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 07 Feb 2014 18:57:43 -0800 (PST)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_34F428C7-0879-4A37-B745-2F89855C787D"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Stephane Brossier <stephane@kill-bill.org>
In-Reply-To: <CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@mail.gmail.com>
Date: Fri, 7 Feb 2014 18:57:40 -0800
Message-Id: <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>
To: Mike Hearn <mike@plan99.net>
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: 1WBy74-0006AU-7m
Cc: "bitcoin-development@lists.sourceforge.net"
	<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: Sat, 08 Feb 2014 02:57:52 -0000


--Apple-Mail=_34F428C7-0879-4A37-B745-2F89855C787D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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:=20
=
https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116a=
a68af368a7

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.

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 =
meantime 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).
>=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


--Apple-Mail=_34F428C7-0879-4A37-B745-2F89855C787D
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; ">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">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 &lt;<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt; 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. &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 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 -&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></body></html>=

--Apple-Mail=_34F428C7-0879-4A37-B745-2F89855C787D--