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 ) 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 ; 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 (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 In-Reply-To: Date: Fri, 7 Feb 2014 18:57:40 -0800 Message-Id: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> References: To: Mike Hearn 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" , 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: 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 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 = 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 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: 

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



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.




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