Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCKXu-0003XI-I4 for bitcoin-development@lists.sourceforge.net; Sun, 09 Feb 2014 02:55:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of kill-bill.org designates 209.85.160.47 as permitted sender) client-ip=209.85.160.47; envelope-from=stephane@kill-bill.org; helo=mail-pb0-f47.google.com; Received: from mail-pb0-f47.google.com ([209.85.160.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WCKXp-0008MD-Ec for bitcoin-development@lists.sourceforge.net; Sun, 09 Feb 2014 02:55:00 +0000 Received: by mail-pb0-f47.google.com with SMTP id rp16so4852676pbb.20 for ; Sat, 08 Feb 2014 18:54:51 -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=D56XjfiZYp1Erl8tjhwDIux5+4pcbNdHTmFpiTf/s2o=; b=mXtMDQWId/TrWTSduM6UiHs4xctgU0vc1PvwL9ygGvNURMUWoeV8XxanapyTDrijV6 e0muvz8F+Yp/w1sTqAX+SIsNUMVu34kKxZj+ThZo3ry+5Zw61+UMXige99HRR2ebQNgP W7CTD553e6VrRXWtrg3x8sO9yOw79PxGQZnWH0ICKsG+pKF0Hy2h9x8XHOHI9cROcihN A80xhT6ftsBV0rHsh52n3VNAIpDp4/nIv/PxBDuYWLjtTInETiv3lsZjinpy3F2DlBSo wwdiF7qU2vxpWjJBi5QCAsVbJ+ROc3r4ow6NeBPSqGHfxFWMHN9U3HbsbfsZQ8HmtGds viqw== X-Gm-Message-State: ALoCoQksb5p0VAhLSpObZ34+PzL3SSRhfNP2FvEo+gL897d6ILNwsvhhO7RDl6enw+M1UAioCM6J X-Received: by 10.66.193.202 with SMTP id hq10mr17292399pac.57.1391914088977; Sat, 08 Feb 2014 18:48:08 -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 si6sm73411800pab.19.2014.02.08.18.48.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Feb 2014 18:48:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Stephane Brossier In-Reply-To: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> Date: Sat, 8 Feb 2014 18:48:06 -0800 Message-Id: References: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> To: Mike Hearn , gavinandresen@gmail.com 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: 1WCKXp-0008MD-Ec 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: Sun, 09 Feb 2014 02:55:02 -0000 --Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mike, Gavin, We started to work on the merchant side to test the integration of our = prototype for the recurring payments. We modified the 'Payment Request = Generator' from Gavin to include a new check box 'set recurring'. We = forked the code and checked in our modification here: = https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7= c3154ad39267c3f3 We also found a few issues with the code diff that we sent yesterday for = bitcoinj and checked in the bug fixes in our fork-- so the diff sent = yesterday is slightly outdated. So at this point we have a working prototype for bitcoinj and we are = waiting for your feedbacks. We also started to look at integrating the = protocol in Kill Bill to check that what is proposed supports indeed the = business cases of a full recurring billing platform. Hope to hear from you guys soon! On Feb 7, 2014, at 6:57 PM, Stephane Brossier = wrote: > Mike and all, >=20 > 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 >=20 > 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. >=20 > At a high level: >=20 > 1. Creation of the subscription: >=20 > The initial handshake for creating the subscription is exactly similar = to the one for the payment protocol (PaymentRequest is used to provide = the contract) >=20 > 2. Wallet can decide to poll the merchants for its active = subscriptions. >=20 > 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. >=20 > Please give us some feedback whenever you have the chance. In the = meantime we will start implementing the merchant side and test the code. >=20 > Cheers! >=20 >=20 >=20 > On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: >=20 >> 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 >=20 --Apple-Mail=_298818E2-BD2E-4AA1-9514-A79EB8D76527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://github.com/killbill/paymentrequest/commi= t/e530f6ec528266aacfd076d7c3154ad39267c3f3

We= also found a few issues with the code diff that we sent yesterday for = bitcoinj and checked in the bug fixes  in our fork-- so the diff = sent yesterday is slightly outdated.

So at this = point we have a working prototype for bitcoinj and we are waiting for = your feedbacks. We also started to look at integrating the protocol in = Kill Bill to check that what is proposed supports indeed the business = cases of a full recurring billing = platform.

Hope to hear from you guys = soon!


On Feb 7, 2014, at 6:57 PM, = 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: 

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=_298818E2-BD2E-4AA1-9514-A79EB8D76527--