Stephane Brossier [ARCHIVE] on Nostr: š Original date posted:2014-02-24 š Original message:Mike, Just want to follow ...
š
Original date posted:2014-02-24
š Original message: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 at 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 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140224/d3d56e7d/attachment.html>;
š Original message: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 at 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 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140224/d3d56e7d/attachment.html>;