public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stephane Brossier <stephane@kill-bill•org>
To: Kevin Greene <kgreenek@gmail•com>
Cc: Pierre-Alexandre Meyer <pierre@kill-bill•org>,
	Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Date: Fri, 14 Feb 2014 12:28:24 -0800	[thread overview]
Message-ID: <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org> (raw)
In-Reply-To: <CAEY8wq40RxeUYYJS2m=xq26iTd2NE64WR7QOUO0+yR-MJQCoxQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3303 bytes --]

Kevin,

We did a second iteration on the prototype to implement subscription cancellation and upgrade/downgrade. We checked in both the bitcoinj and php server to be able to test it.
We also worked on our side of the merchant implementation (Kill Bill) to feel confident that the protocol will support advanced business cases. At this point it is looking promising, but more work is needed to conclude.

We wanted to follow up on a few pervious points you raised:

> However, continuing to think about this even more, maybe the simple memo field along with an empty set of outputs is enough already.

From our merchant side (Kill Bill), we do indeed use this field to report successes or errors. Maybe it would be useful to extend PaymentACK with a boolean success field (so the wallet doesn't commit the transaction in case of failures)?

> One high-level comment -- the wallet in this design doesn't have any way of knowing when the payments are supposed to end. I feel this is important to show to the user before they start their wallet polling infinitely.

We extended our RecurringPaymentDetails message to support this use case, as it solves the problem of subscription changes and cancellations for free.

We introduced the concept of a subscription, referred to by a unique id (the tuple merchant_id,subscription_id should be globally unique), which has multiple contracts (RecurringPaymentContract). Besides payment bounds, each contract has a validity period: generally, a subscription will have a unique active contract at a given time and potentially one or more pending ones.

For example, say you are on the gold plan (1 BTC/mo.) and want to downgrade to a bronze plan (0.5 BTC/mo.) at your next billing date. Wshen you click "Downgrade" on the merchant site, you will update your wallet with two contracts: the current valid one until your next billing date (for up to 1 BTC), and a pending one, starting at your next billing date (for up to 0.5 BTC/mo. and without an ending date).
Upon cancellation of the bronze plan, the end date of the contract will be updated and polling will stop eventually.

All of this contract metadata is returned to the wallet so the user can make an informed decision.


Thanks for your feedbacks!

S.


On Feb 11, 2014, at 10:37 PM, Kevin Greene <kgreenek@gmail•com> wrote:

> Sending this again and truncating since apparently the message body was too long.
> 
> Thanks for humoring my questions!
> 
> >I think reporting such errors to the wallet would make complete sense. However i am not clear why we would a separate url for that?
> 
> Hmm, thinking about this more, adding a simple status_code in PaymentRequest would be a much easier way to achieve this. However, continuing to think about this even more, maybe the simple memo field along with an empty set of outputs is enough already.
> 
> In bitcoinj, right now the code will throw a PaymentRequestException.InvalidOutputs exception if the set of outputs is empty with a message of "No Outputs". Because of that, there isn't a good way to tell the difference between a payment request that had no outputs and a payment request that had some invalid output(s).
> 
> Question to everyone:
> How does bitcoin-qt handle a PaymentRequest with no outputs?


[-- Attachment #2: Type: text/html, Size: 5138 bytes --]

  reply	other threads:[~2014-02-14 20:28 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 [this message]
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=5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org \
    --to=stephane@kill-bill$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=kgreenek@gmail$(echo .)com \
    --cc=pierre@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