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 ) id 1W9Ib9-0004K9-Ms for bitcoin-development@lists.sourceforge.net; Fri, 31 Jan 2014 18:13:51 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.181 as permitted sender) client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f181.google.com; Received: from mail-ob0-f181.google.com ([209.85.214.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W9Ib6-0000WZ-Bw for bitcoin-development@lists.sourceforge.net; Fri, 31 Jan 2014 18:13:51 +0000 Received: by mail-ob0-f181.google.com with SMTP id va2so5392733obc.12 for ; Fri, 31 Jan 2014 10:13:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.92.231 with SMTP id cp7mr1424762obb.82.1391192022924; Fri, 31 Jan 2014 10:13:42 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Fri, 31 Jan 2014 10:13:42 -0800 (PST) In-Reply-To: References: Date: Fri, 31 Jan 2014 19:13:42 +0100 X-Google-Sender-Auth: 9Q5Kv5uyTaR0N3Uhonzxq5gIwp8 Message-ID: From: Mike Hearn To: Stephane Brossier Content-Type: multipart/alternative; boundary=001a11c302cc57422d04f14822e0 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: 1W9Ib6-0000WZ-Bw Cc: "bitcoin-development@lists.sourceforge.net" , Pierre-Alexandre Meyer 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 18:13:51 -0000 --001a11c302cc57422d04f14822e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > > > > > > > > > > > > > > *From what I have seen so far, there seems to be an agreement that this i= s > 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 consensu= s > via email. I am certainly open to follow 'the way' if there is one, but o= ne > 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 whic= h > I am interested to pursue if that makes sense.We have quite some experien= ce > 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 mig= ht > have missedSo, 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 mai= n > goal here is to have the customer subscribe to a service of some kind (th= at > is, agreeing on the terms of that subscription contract), and then have t= he > wallet make recurring payments without any intervention from the customer > as long as the payments match what the customer agreed on paying.An examp= le > of such service would be an online streaming website, to which a user pay= s > 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 typ= e > of billing is more complicated and there are many variations to it used i= n > 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 sur= e > 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 push model presents new a= dvantages > 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 th= e > 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 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 mor= e > 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 t= o > the merchant.6. The merchant confirms the subscription was created.Ongoin= g > 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 on > 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 credit= s, > invoice adjustments, etc. since the last invoice, so the amount to pay fo= r > a given billing period may be lower than the regular amount. It could eve= n > 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 ope= ns > 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 matc= h > 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 walle= t > and of course checks the states of the transactions on the btcnet to mark > 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 ver= y > similar to the initial registration.1. The customer clicks 'upgrade', > 'downgrade', =E2=80=A6 -> A msg is sent to the merchant.2. The merchant s= ends back > a msg to the wallet with the detail of the NEW subscription. 3. The walle= t > 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 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 th= e > subscription was cancelled.* > --001a11c302cc57422d04f14822e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That looks OK at a very high level. Things you probably wa= nt to think about:
  • How to trigger it off the existing payment p= rotocol (no new top level messages or mime types or uri extensions please)<= /li>
  • Data structures to define the payment schedule
  • Do you allow pre= -submission of time locked transactions or not?
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).



On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <st= ephane@kill-bill.org> wrote:
From what I have seen so far, there seems to be an a= greement that this is a nice feature to add.
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.


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:
* some feedbacks on the high level proposal
* additional requirements we might have missed<= /span>


I. Abstract
---------------

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

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.


III. Flow of Operations
--------------------= --------------------


Creation of the subscription:
- - - - - - - - - - - - - - - - - - - - - -

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 th= e prototype implementation this is sufficient.
3. The wallet prompts the customer for authoriz= ation.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the mer= chant.
6. The merchant confirms the subscription was c= reated.

Ongoing payments:=
- - - - - - - - - - - - - - - -

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.


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.


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.

Subscription chan= ge (optional):
- - - - - - - - - - - - - - - - - - - - - - - -

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.
2. The merchant sends back a msg to the wallet = with the detail of the NEW subscription.
3. The wallet prompts the customer for authoriz= ation.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the mer= chant.
6. The merchant confirms the change in the subs= cription.

Cancellation of t= he subscription:
- - - - - - - - - - - - - - - - - - - - - - - - -

The cancellation is initiated from th= e customer:

1. The customer clicks 'cancel= 9; -> The wallet is informed that it =C2=A0should not accept any new pay= ment associated to that subscription.
2. The wallet sends a message to the merchant t= o inform about the cancellation.
3. The merchant confirms the subscription was c= ancelled.



--001a11c302cc57422d04f14822e0--