[Bitcoin-development] Extension for BIP-0070 to support recurring payments

[Mike Hearn]

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 at 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 missedSo, 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.*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140131/9beb6bd1/attachment.html>