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'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.</p> <div class=3D"gmail_quote">On 8 Feb 2014 08:28, "Stephane Brossier&quo= t; <<a href=3D"mailto:stephane@kill-bill.org">stephane@kill-bill.org</a>= > 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 'recurring' 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 <<a hr= ef=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>> 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"><<a href=3D"mailto:stephane@kill-bill.org" target=3D"_blank">st= ephane@kill-bill.org</a>></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't know exactly what the process is, and in particular how = we reach consensus via email. I am certainly open to follow 'the way= 9; if there is one, but one solution would be to follow Mike'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 'subscribe= ' -> 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 'push' 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'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'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 'upgrade', 'downgrade', =E2=80=A6 = -> 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 'cancel= 9; -> 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--