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 <steph...@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 <kgree...@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?
>
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
