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