public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stephane Brossier <stephane@kill-bill.org>
To: Mike Hearn <mike@plan99.net>
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: Mon, 24 Feb 2014 10:04:21 -0800	[thread overview]
Message-ID: <81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org> (raw)
In-Reply-To: <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org>

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

Mike,


Just want to follow up with you and the community in general regarding the BIP0070 extension for recurring billing. At this point we have a working prototype that we checked-in in our fork of bitcoinj (https://github.com/killbill/bitcoinj). We tested it by extending the php 'payment server' from Gavin which we also check-in in a fork (https://github.com/killbill/paymentrequest). I think it does not make much sense from our side to invest more efforts until we hear some feedbacks.

Once we agree/integrate any feedbacks you guys may have-- a proposal for next steps would be:
* Turn that into a actual BIP so as to detail how that works, 
* Write some more serious unit tests
* Merge back code into bitconj trunk

Down the line write the C++ code, but of course that would assume BIP0070 is also implemented in C++ as we rely on it.

I understand you guys may have more important matters to solve these days with the recent malleability issue, but i want to make it clear that we are waiting for feedbacks to make additional progress.

Thanks!

S.




On Feb 14, 2014, at 12:28 PM, Stephane Brossier <stephane@kill-bill.org> wrote:

> 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: 6983 bytes --]

  reply	other threads:[~2014-02-24 18:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28  2:36 [Bitcoin-development] Extension for BIP-0070 to support recurring payments 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 [this message]
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=81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org \
    --to=stephane@kill-bill.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    --cc=pierre@kill-bill.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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