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.



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.
Bitcoin-development mailing list

Reply via email to