From: Mike Hearn <mike@plan99•net>
To: Stephane Brossier <stephane@kill-bill•org>
Cc: "bitcoin-development@lists•sourceforge.net"
<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: Fri, 31 Jan 2014 19:13:42 +0100 [thread overview]
Message-ID: <CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@mail.gmail.com> (raw)
In-Reply-To: <D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
[-- Attachment #1: Type: text/plain, Size: 7457 bytes --]
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 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.*
>
[-- Attachment #2: Type: text/html, Size: 19947 bytes --]
next prev parent reply other threads:[~2014-01-31 18:13 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 [this message]
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
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='CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@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