From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8Lb0-0001lm-2E for bitcoin-development@lists.sourceforge.net; Wed, 29 Jan 2014 03:13:46 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of kill-bill.org designates 209.85.220.53 as permitted sender) client-ip=209.85.220.53; envelope-from=stephane@kill-bill.org; helo=mail-pa0-f53.google.com; Received: from mail-pa0-f53.google.com ([209.85.220.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8Lay-0005qp-Cv for bitcoin-development@lists.sourceforge.net; Wed, 29 Jan 2014 03:13:45 +0000 Received: by mail-pa0-f53.google.com with SMTP id lj1so1198007pab.26 for ; Tue, 28 Jan 2014 19:13:38 -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=vx394nTvXexE98k+NcH8OTgJVjD86oYcIuV60mycoe0=; b=XITYygX7+qGRc6ABe5pIUCcPcrAmi4jr+U3tCNOKALAff8Ic0hgmCW1WRDHDtCqOut SySp30DmRsVBQmEyurEMepwEKRCvoz0myl/DxAvA6HYbPxgpsRz9fgRBTQ1iwDp2JN8t P9xQhsG80W/Cs3V2q91ut4Nj0eNuIAYqvYmlWSyI3hjVx4ADN4jqFlaJzVw8WB7RiieW BoMj+fgdEVxIZy08fFHpMBPt/uEqs9frXOiKwjwt7xeLWU0cLuu32tkwVeYYV+zk7AP5 2KcJXlmioVO86GZQv+J2pmp+Ro3C+lAxz/QiR8W4+PFkLNuQryDQBdOTSm3GtzZQIlH2 2lRA== X-Gm-Message-State: ALoCoQm5x3+KjGg/XI95pzBuZI2VqGhhZdtnxgCU7n6U2B0N2ZAlaVq6lnAq5kWXOJSnfNocrdjM X-Received: by 10.68.174.37 with SMTP id bp5mr5126320pbc.15.1390963642585; Tue, 28 Jan 2014 18:47:22 -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 nw11sm4999932pab.13.2014.01.28.18.47.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 18:47:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F85DE2C-A91D-4290-9E42-EE050BD2B258" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Stephane Brossier In-Reply-To: Date: Tue, 28 Jan 2014 18:47:20 -0800 Message-Id: References: To: "bitcoin-development@lists.sourceforge.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: 1W8Lay-0005qp-Cv Cc: Pierre-Alexandre Meyer , PikaPay 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: Wed, 29 Jan 2014 03:13:46 -0000 --Apple-Mail=_2F85DE2C-A91D-4290-9E42-EE050BD2B258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =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. 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 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 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 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. 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. 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.=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. III. Flow of Operations ---------------------------------------- Creation of the subscription: - - - - - - - - - - - - - - - - - - - - - -=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. Ongoing payments: - - - - - - - - - - - - - - - - =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. 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. 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 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. Subscription change (optional): - - - - - - - - - - - - - - - - - - - - - - - -=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. 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. Cancellation of the subscription: - - - - - - - - - - - - - - - - - - - - - - - - -=20 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 the subscription was cancelled. --Apple-Mail=_2F85DE2C-A91D-4290-9E42-EE050BD2B258 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=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.


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

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

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.


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


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

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

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.


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

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 very similar to the initial = registration.

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

- - - - - - - - - - - - - - - - - - - - - - - - = -
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 the subscription was = cancelled.


= --Apple-Mail=_2F85DE2C-A91D-4290-9E42-EE050BD2B258--