From: Mike Hearn <mike@plan99•net>
To: Stephane Brossier <stephane@kill-bill•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Pierre-Alexandre Meyer <pierre@kill-bill•org>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Date: Tue, 11 Feb 2014 17:24:12 +0100 [thread overview]
Message-ID: <CANEZrP0Pzux7R5fJAa57JhLOn3AskD5tVSNNf9OQj7S=P3gJcw@mail.gmail.com> (raw)
In-Reply-To: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org>
[-- Attachment #1: Type: text/plain, Size: 9260 bytes --]
Hey guys,
I'm on vacation now so won't be able to take a look until I'm back in a
couple of weeks but the approach sounds reasonable based on your
description.
On 8 Feb 2014 08:28, "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:
>
> https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7
>
> 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:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From 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, …). For
>> the sake of discussion, we’ll 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’s 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: *
>>
>> *- - - - - - - - - - - - - - - - *
>>
>>
>>
>>
>>
>>
>> * 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 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, …
>> 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', … -> 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. *
>>
>
>
>
[-- Attachment #2: Type: text/html, Size: 22382 bytes --]
prev parent reply other threads:[~2014-02-11 16:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 2:36 Stephane Brossier
2014-01-28 3:58 ` Kevin Greene
2014-01-28 4:29 ` Jeff Garzik
2014-01-28 4:43 ` Jeff Garzik
2014-01-28 5:07 ` PikaPay
2014-01-28 6:08 ` Odinn Cyberguerrilla
2014-01-28 6:48 ` Jeff Garzik
2014-01-28 6:34 ` Mike Hearn
2014-01-29 2:47 ` Stephane Brossier
2014-01-31 18:13 ` Mike Hearn
2014-02-08 2:57 ` Stephane Brossier
2014-02-09 2:48 ` Stephane Brossier
2014-02-11 10:00 ` Kevin Greene
2014-02-11 18:01 ` Stephane Brossier
2014-02-12 6:32 ` Kevin Greene
2014-02-12 6:37 ` Kevin Greene
2014-02-14 20:28 ` Stephane Brossier
2014-02-24 18:04 ` Stephane Brossier
2014-02-25 16:29 ` Mike Hearn
2014-02-25 18:40 ` Drak
2014-02-25 19:03 ` Jeremy Spilman
2014-02-25 19:06 ` Christophe Biocca
2014-02-26 3:53 ` Stephane Brossier
2014-02-26 10:30 ` Mike Hearn
2014-02-11 16:24 ` Mike Hearn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP0Pzux7R5fJAa57JhLOn3AskD5tVSNNf9OQj7S=P3gJcw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pierre@kill-bill$(echo .)org \
--cc=stephane@kill-bill$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox