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

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.

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