Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Thanks for the explanation. I agree that makes sense, and you did actually explain this before, I just didn't connect the dots :) The accompanying BIP should explain all this, so the rationale for the design and how you use it is made clear to developers. I've CCd Jeff and Stephen on this thread, so they can go review it and weigh in with any comments. They may want to go back to customers who requested this feature and ask if it'd satisfy their needs. On Wed, Feb 26, 2014 at 9:23 AM, Stephane Brossier wrote: > > > > > > > *Hi Mike, Jeremy, Drak,Before going through your questions, I would like > to bring some clarity on a few key elements in that protocol. There are > really two aspects to it: 1. The contract negotiation; when the user first > subscribes, it is prompted by a contract that will define the payment > bounds associated with that subscription. 2. Once accepted, the wallet is > in charge and the user does not have to interact anymore -- this is the > point of the recurring payment protocol. The wallet will poll the merchant > and issue payments as they are requested by the merchant as long as they > stay within the bounds of what was specified by the contract (and accepted > by the customer).I think it would help to explain how we ended up with the > type of contract we introduced in that protocol. In an ideal world and in a > NON recurring scheme, the contract should simply be the exact amount to be > paid. In our case the exact amount may not be completely known in advance > -- for e.g taxes, shipping, pro-rations, … and so we decided to introduce > first a max amount per payment, and also a max amount per period. It is up > to the merchant to decide whether to specify none, any or both bounds (max > amount per payment and max amount per period). By specifying both, the > contract is tighter and the client would feel safer to accept it. In the > extreme case, by specifying none, the client would be presented with a > contract to pay whatever is requested -- probably not a good option in the > Bitcoin world unless there is a high sense of trust with the merchant. > From reading your comments, it appears we have not been clear on how that > frequency (PaymentFrequencyType) is being used. Its sole purpose is to > define the max amount per period in the contract. The frequency of the > payment is implicitly dictated by the merchant but not specified in the > protocol by design: the wallet has to poll with a fine granularity (ideally > each day when it is up) to understand if there is something pending. In the > same way, a specified amount was not enough in the contract, we feel it > would be restrictive to specify in advance when payments are due. There are > a lot of complex scenarios in the billing space, and having the wallet poll > the merchant to inquire for pending payments is the most flexible option > and the contract is there to ensure the client will not be abused. To give > a concrete example, imagine a data plan where you pay a base recurring > price of $70 per month, but you are charged $10 per GB of data used beyond > your included limit. If you exceed your limit on the 15th and the 23rd of a > given month, two extra payment attempts will be requested by the merchant, > that you couldn’t predict (this scenario is often referred to as usage > billing with Prepay Credits and Top-up, where the customer pays in advance > for blocks of N units, and once they are consumed another N are purchased).* > > > *See answers in your questions inlined below:* > > > I have the following comments: > >1. There's no need to serialize RecurringPaymentDetails as bytes here. >It's done that way outside of PaymentDetails in order to support digital >signatures over protobufs that may have extensions the wallet app isn't >aware of, but it's a pain and inside PaymentDetails (and therefore for most >extensions) it shouldn't be necessary. So you can just use "optional >RecurringPamentDetails recurring_payments = 8;" > > > > OK, we'll fix it. > > > >1. There's only 4 possibilities here for recurrences. That seems >rather restrictive. Is the cost of being more expressive really so high? >Why not allow more flexible specification of periods? > > >1. If there's no payment_frequency_type field then what happens? A >quirk of protobufs to be aware of is that making an enum field "required" >can hurt backwards compatibility. Because it will be expressed using a >languages underlying enum type, if there's a new enum member added later >old software that attempts to deserialize this will throw exceptions >because the new "unknown" member would be unrepresentable in the old model. >Making the field optional avoids this problem (it will be treated as >missing instead) but means software needs to be written to know what to do >when it can't read the enum value / sees enum values from the future. > > > > I hope the explanation above answers the
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hi Mike, Jeremy, Drak, Before going through your questions, I would like to bring some clarity on a few key elements in that protocol. There are really two aspects to it: The contract negotiation; when the user first subscribes, it is prompted by a contract that will define the payment bounds associated with that subscription. Once accepted, the wallet is in charge and the user does not have to interact anymore -- this is the point of the recurring payment protocol. The wallet will poll the merchant and issue payments as they are requested by the merchant as long as they stay within the bounds of what was specified by the contract (and accepted by the customer). I think it would help to explain how we ended up with the type of contract we introduced in that protocol. In an ideal world and in a NON recurring scheme, the contract should simply be the exact amount to be paid. In our case the exact amount may not be completely known in advance -- for e.g taxes, shipping, pro-rations, … and so we decided to introduce first a max amount per payment, and also a max amount per period. It is up to the merchant to decide whether to specify none, any or both bounds (max amount per payment and max amount per period). By specifying both, the contract is tighter and the client would feel safer to accept it. In the extreme case, by specifying none, the client would be presented with a contract to pay whatever is requested -- probably not a good option in the Bitcoin world unless there is a high sense of trust with the merchant. From reading your comments, it appears we have not been clear on how that frequency (PaymentFrequencyType) is being used. Its sole purpose is to define the max amount per period in the contract. The frequency of the payment is implicitly dictated by the merchant but not specified in the protocol by design: the wallet has to poll with a fine granularity (ideally each day when it is up) to understand if there is something pending. In the same way, a specified amount was not enough in the contract, we feel it would be restrictive to specify in advance when payments are due. There are a lot of complex scenarios in the billing space, and having the wallet poll the merchant to inquire for pending payments is the most flexible option and the contract is there to ensure the client will not be abused. To give a concrete example, imagine a data plan where you pay a base recurring price of $70 per month, but you are charged $10 per GB of data used beyond your included limit. If you exceed your limit on the 15th and the 23rd of a given month, two extra payment attempts will be requested by the merchant, that you couldn’t predict (this scenario is often referred to as usage billing with Prepay Credits and Top-up, where the customer pays in advance for blocks of N units, and once they are consumed another N are purchased). See answers in your questions inlined below: > > I have the following comments: > There's no need to serialize RecurringPaymentDetails as bytes here. It's done > that way outside of PaymentDetails in order to support digital signatures > over protobufs that may have extensions the wallet app isn't aware of, but > it's a pain and inside PaymentDetails (and therefore for most extensions) it > shouldn't be necessary. So you can just use "optional RecurringPamentDetails > recurring_payments = 8;" > OK, we'll fix it. > There's only 4 possibilities here for recurrences. That seems rather > restrictive. Is the cost of being more expressive really so high? Why not > allow more flexible specification of periods? > If there's no payment_frequency_type field then what happens? A quirk of > protobufs to be aware of is that making an enum field "required" can hurt > backwards compatibility. Because it will be expressed using a languages > underlying enum type, if there's a new enum member added later old software > that attempts to deserialize this will throw exceptions because the new > "unknown" member would be unrepresentable in the old model. Making the field > optional avoids this problem (it will be treated as missing instead) but > means software needs to be written to know what to do when it can't read the > enum value / sees enum values from the future. > I hope the explanation above answers the questions. > I assume the amounts are specified in terms of satoshi, and timestamps are > UNIX time, but better to make that explicit. > Yes. > Seems there's an implicit value constraint that max_payment_amount <= > max_payment_per_period. What happens if that constraint is violated? Best to > document that. > As explained above, contract would define none, 1 or both conditions. First the merchant should not return such 'conditions' but if it does the client should not accept the contract. If the client decides to accept it anyway, then the wallet just verifies both conditions are met separately regardless of whether there is
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Given the enormous number of variations on time periods for a
recurring payment, might it be better to simple allow a list of
timestamps? It costs almost nothing, bandwidth wise, and shifts the
thinking to the merchant platform. That doesn't give you an infinite
time frame, but you just get a new list of timestamps every time you
pay the service.
Continuing that thought, is a "next_payment_time" field with each
incremental transaction enough to cover everything?
On Tue, Feb 25, 2014 at 1:40 PM, Drak wrote:
> Forgive me if I missed it, but the spec doesnt look like it can handle only
> handle periods of per week, per month, per quarter rather than 'n period'. I
> take Paypal as a reference example for subscription payments where you can
> set recurring to every: n days, n weeks, n months, n years. That way a
> quarterly payment is every 3 months. This fine granularity is necessary
> because sometime a payment scheme can be per 4 weekly rather than per
> monthly.
>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
> and you can drop quarterly since it's just expressed as per 3*monthly.
>
> Drak
>
>
> On 25 February 2014 16:29, Mike Hearn wrote:
>>
>> Hey there,
>>
>> So the essence of this protocol is as follows:
>>
>>
>> enum PaymentFrequencyType {
>> WEEKLY = 1;
>> MONTHLY = 2;
>> QUARTERLY = 3;
>> ANNUAL = 4;
>> }
>> message RecurringPaymentDetails {
>> // Namespace for the merchant such as org.foo.bar
>> required string merchant_id = 1;
>>
>>
>> // Id for the recurring subscription
>> required bytes subscription_id = 2;
>>
>>
>> // Contracts associated with a given subscription
>> repeated RecurringPaymentContract contracts = 3;
>>
>>
>> }
>> message RecurringPaymentContract {
>>
>>
>> // Unique id for a given contract
>> required bytes contract_id = 1;
>>
>>
>> // URL to poll to get the next PaymentRequest
>> required string polling_url = 2;
>>
>>
>> // Timestamp; when this contract starts
>> required uint64 starts = 3;
>>
>>
>> // Timestamp; when this contract should be considered invalid
>> optional uint64 ends = 4;
>>
>>
>> // Expected payment frequency
>> optional PaymentFrequencyType payment_frequency_type = 5;
>>
>>
>> // Max payment amount within that frequency (e.g. no more than 5
>> BTC per month)
>> optional uint64 max_payment_per_period = 6;
>>
>>
>> // Max payment amount (e.g. no more than 3 BTC per payment)
>> optional uint64 max_payment_amount = 7;
>>
>>
>> }
>>
>> I have the following comments:
>>
>> There's no need to serialize RecurringPaymentDetails as bytes here. It's
>> done that way outside of PaymentDetails in order to support digital
>> signatures over protobufs that may have extensions the wallet app isn't
>> aware of, but it's a pain and inside PaymentDetails (and therefore for most
>> extensions) it shouldn't be necessary. So you can just use "optional
>> RecurringPamentDetails recurring_payments = 8;"
>>
>> There's only 4 possibilities here for recurrences. That seems rather
>> restrictive. Is the cost of being more expressive really so high? Why not
>> allow more flexible specification of periods?
>>
>> If there's no payment_frequency_type field then what happens? A quirk of
>> protobufs to be aware of is that making an enum field "required" can hurt
>> backwards compatibility. Because it will be expressed using a languages
>> underlying enum type, if there's a new enum member added later old software
>> that attempts to deserialize this will throw exceptions because the new
>> "unknown" member would be unrepresentable in the old model. Making the field
>> optional avoids this problem (it will be treated as missing instead) but
>> means software needs to be written to know what to do when it can't read the
>> enum value / sees enum values from the future.
>>
>> I assume the amounts are specified in terms of satoshi, and timestamps are
>> UNIX time, but better to make that explicit.
>>
>> Seems there's an implicit value constraint that max_payment_amount <=
>> max_payment_per_period. What happens if that constraint is violated? Best to
>> document that.
>>
>> What's the "merchant ID" namespace thing about? What's it for? What
>> happens if I set my competitors merchant ID there?
>>
>> What's the "subscription ID"? Is this stuff not duplicative/redundant with
>> the existing merchant_data field?
>>
>> In what situations would you have >1 contract per payment request? I'm not
>> sure I understand why it's repeated. Presumably if there are zero contracts
>> included the data should be ignored, or an error thrown and the entire
>> payment request rejected? Which should it be?
>>
>> It's unclear to me given such a contract when the payment should actually
>> occur. For instance if it's "monthl
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period >(one of daily, weekly, monthly,
> yearly): and you can drop quarterly since it's just expressed as per
> >3*monthly.
If you're going to go the direction of a {unitType, unitsPerInterval}
tuple, then I think the only two units you could ever want are minutes and
months. All other standard units of time can be expressed in terms of
those two, right?
Also consider changing "optional uint64 ends = 4;" to be a interval count
instead of a UTC timestamp, to avoid any ambiguity over how the 'while'
loop should be implemented.
--
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
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Forgive me if I missed it, but the spec doesnt look like it can handle only
handle periods of per week, per month, per quarter rather than 'n period'.
I take Paypal as a reference example for subscription payments where you
can set recurring to every: n days, n weeks, n months, n years. That way a
quarterly payment is every 3 months. This fine granularity is necessary
because sometime a payment scheme can be per 4 weekly rather than per
monthly.
So in summary the spec needs daily as an option, and to specify the
recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
and you can drop quarterly since it's just expressed as per 3*monthly.
Drak
On 25 February 2014 16:29, Mike Hearn wrote:
> Hey there,
>
> So the essence of this protocol is as follows:
>
> enum PaymentFrequencyType {
>
> WEEKLY = 1;
>
> MONTHLY = 2;
>
> QUARTERLY = 3;
>
> ANNUAL = 4;
> }
> message RecurringPaymentDetails {
> // Namespace for the merchant such as org.foo.bar
>
> required string merchant_id = 1;
>
> // Id for the recurring subscription
> required bytes subscription_id = 2;
>
> // Contracts associated with a given subscription
>
> repeated RecurringPaymentContract contracts = 3;
>
> }
> message RecurringPaymentContract {
>
> // Unique id for a given contract
>
> required bytes contract_id = 1;
>
> // URL to poll to get the next PaymentRequest
>
> required string polling_url = 2;
>
> // Timestamp; when this contract starts
> required uint64 starts = 3;
>
> // Timestamp; when this contract should be considered invalid
>
> optional uint64 ends = 4;
>
> // Expected payment frequency
> optional PaymentFrequencyType payment_frequency_type = 5;
>
> // Max payment amount within that frequency (e.g. no more than 5 BTC
> per month)
>
> optional uint64 max_payment_per_period = 6;
>
> // Max payment amount (e.g. no more than 3 BTC per payment)
>
> optional uint64 max_payment_amount = 7;
>
> }
>
> I have the following comments:
>
>1. There's no need to serialize RecurringPaymentDetails as bytes here.
>It's done that way outside of PaymentDetails in order to support digital
>signatures over protobufs that may have extensions the wallet app isn't
>aware of, but it's a pain and inside PaymentDetails (and therefore for most
>extensions) it shouldn't be necessary. So you can just use "optional
>RecurringPamentDetails recurring_payments = 8;"
>
>2. There's only 4 possibilities here for recurrences. That seems
>rather restrictive. Is the cost of being more expressive really so high?
>Why not allow more flexible specification of periods?
>
>3. If there's no payment_frequency_type field then what happens? A
>quirk of protobufs to be aware of is that making an enum field "required"
>can hurt backwards compatibility. Because it will be expressed using a
>languages underlying enum type, if there's a new enum member added later
>old software that attempts to deserialize this will throw exceptions
>because the new "unknown" member would be unrepresentable in the old model.
>Making the field optional avoids this problem (it will be treated as
>missing instead) but means software needs to be written to know what to do
>when it can't read the enum value / sees enum values from the future.
>
>4. I assume the amounts are specified in terms of satoshi, and
>timestamps are UNIX time, but better to make that explicit.
>
>5. Seems there's an implicit value constraint that max_payment_amount
><= max_payment_per_period. What happens if that constraint is violated?
>Best to document that.
>
>6. What's the "merchant ID" namespace thing about? What's it for? What
>happens if I set my competitors merchant ID there?
>
>7. What's the "subscription ID"? Is this stuff not
>duplicative/redundant with the existing merchant_data field?
>
>8. In what situations would you have >1 contract per payment request?
>I'm not sure I understand why it's repeated. Presumably if there are zero
>contracts included the data should be ignored, or an error thrown and the
>entire payment request rejected? Which should it be?
>
>9. It's unclear to me given such a contract when the payment should
>actually occur. For instance if it's "monthly" then what day in the month
>would the payment occur?
>
>10. You'll notice I moved the comments to be above the field
>definitions. I know the current proto isn't done that way, but let's change
>it - long comments are good and putting them above the field definitions
>encourages people to write enough detail without being put off by line
>length constraints
>
>
> I think the next step would be to talk to BitPay/get Jeff+Stephen involved
> because I know they have customers that really want
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string merchant_id = 1;
// Id for the recurring subscription
required bytes subscription_id = 2;
// Contracts associated with a given subscription
repeated RecurringPaymentContract contracts = 3;
}
message RecurringPaymentContract {
// Unique id for a given contract
required bytes contract_id = 1;
// URL to poll to get the next PaymentRequest
required string polling_url = 2;
// Timestamp; when this contract starts
required uint64 starts = 3;
// Timestamp; when this contract should be considered invalid
optional uint64 ends = 4;
// Expected payment frequency
optional PaymentFrequencyType payment_frequency_type = 5;
// Max payment amount within that frequency (e.g. no more than
5 BTC per month)
optional uint64 max_payment_per_period = 6;
// Max payment amount (e.g. no more than 3 BTC per payment)
optional uint64 max_payment_amount = 7;
}
I have the following comments:
1. There's no need to serialize RecurringPaymentDetails as bytes here.
It's done that way outside of PaymentDetails in order to support digital
signatures over protobufs that may have extensions the wallet app isn't
aware of, but it's a pain and inside PaymentDetails (and therefore for most
extensions) it shouldn't be necessary. So you can just use "optional
RecurringPamentDetails recurring_payments = 8;"
2. There's only 4 possibilities here for recurrences. That seems rather
restrictive. Is the cost of being more expressive really so high? Why not
allow more flexible specification of periods?
3. If there's no payment_frequency_type field then what happens? A quirk
of protobufs to be aware of is that making an enum field "required" can
hurt backwards compatibility. Because it will be expressed using a
languages underlying enum type, if there's a new enum member added later
old software that attempts to deserialize this will throw exceptions
because the new "unknown" member would be unrepresentable in the old model.
Making the field optional avoids this problem (it will be treated as
missing instead) but means software needs to be written to know what to do
when it can't read the enum value / sees enum values from the future.
4. I assume the amounts are specified in terms of satoshi, and
timestamps are UNIX time, but better to make that explicit.
5. Seems there's an implicit value constraint that max_payment_amount <=
max_payment_per_period. What happens if that constraint is violated? Best
to document that.
6. What's the "merchant ID" namespace thing about? What's it for? What
happens if I set my competitors merchant ID there?
7. What's the "subscription ID"? Is this stuff not duplicative/redundant
with the existing merchant_data field?
8. In what situations would you have >1 contract per payment request?
I'm not sure I understand why it's repeated. Presumably if there are zero
contracts included the data should be ignored, or an error thrown and the
entire payment request rejected? Which should it be?
9. It's unclear to me given such a contract when the payment should
actually occur. For instance if it's "monthly" then what day in the month
would the payment occur?
10. You'll notice I moved the comments to be above the field
definitions. I know the current proto isn't done that way, but let's change
it - long comments are good and putting them above the field definitions
encourages people to write enough detail without being put off by line
length constraints
I think the next step would be to talk to BitPay/get Jeff+Stephen involved
because I know they have customers that really want recurring payments, and
those guys will have a clearer idea of customer requirements than we do. I
feel uncomfortable with designing or reviewing in a vacuum without some
actual people who would use it chiming in, as I don't really know much
about the underlying business processes.
I have some other comments about the bitcoinj implementation specifically -
for instance, we don't have a "wallet directory" concept: everything goes
into the wallet file. So we'll need to think about how to structure the
code to allow that. Also, just using a background polling thread is likely
not flexible enough, as on some platforms you can't stay running all the
time (e.g. Android) without upsetting people, but the underlying OS can
wake you up at the right times, so wallet apps should have an ability to
control wakeup tasks. But we can discuss that over on the bitcoinj list
specifically. Let's keep this thread for the general protoc
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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 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 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
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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 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? -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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". 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? On Tue, Feb 11, 2014 at 10:01 AM, Stephane Brossier wrote: > Hi Kevin, > > On Feb 11, 2014, at 2:00 AM, Kevin Greene wrote: > > Figured I would have a crack at reviewing this since Mike is out for a > bit. It was great running into you guys at the bitcoin fair in SF! Small > world :) > > > Indeed! It was great meeting you! It's always nice to meet people in > person... > > I like how simple this is. You just give it an url to fetch the next > payment request and a date to fetch it. > > What should happen if the client tries to fetch the PaymentRequest early > or late? > > > If the client tries to fetch too early, then the merchant will return a > PaymentRequest with no output (there is nothing to pay yet). If it fetches > too late, this is merchant specific. It could be that the service got > discontinued -- extreme case -- or that there are now multiple > PaymentRequest pending or that the merchant decided to aggregate those into > one. In that scenario, it could lead to a case where the amount to pay goes > beyond the contract and the wallet would refuse to make the recurring > payment. > > Does it become valid after some date and stay valid for some length of > time? > > > The protocol we sketched does not include (yet) an expiration date. At > this point the contract is fairly minimal, and we could envision adding > more parameters such as expiration date. So at this point the behavior > would be dictated by the merchant. > > Also, what should happen if the client tries to consume the same > PaymentRequest twice (or multiple times) during the same period? > > > The merchant initiates the PaymentRequest and is in charge to make sure > they match the invoices that the client should pay. On the client side, the > wallet is responsible to verify that the contract is respected, so if a > merchant were to issue multiple times the same PaymentRequest, the wallet > would detect it goes beyond the bonds defined in the contract and would > refuse to make the additional Payments. > > I do not think daily/weekly/monthly is flexible enough. What do you think > about having a concrete start time and end time when the next > PaymentRequest will be valid? > > > I agree that daily/weekly/monthly may not be flexible enough. However > specifying a fixed date may be very tricky because in some cases a monthly > subscription may start on a 31st of a month, and depending on the month, > the due date will vary -- could be 30th, 28th, 29th, ... Also note that the > frequency (daily/weekly/monthly) is not used as a polling interval, but is > only used to verify the contract is respected. > > There are multiple viable options to specify that contract and ideally we > could/should support multiple schemes; different merchants could use > different schemes, and the client would decide wether or not he is ready to > accept the terms that will later be enforced by the wallet. But of course > all this flexibility goes against simplicity and so this is tradeoff... > > > This also prevents the wallet from having to remember when it last sent a > payment and getting skewed over time. > > > Today, our current prototype is polling every day -- which is the lowest > granularity we introduced -- and so there is no risk of getting skewed. > > > When a wallet hits the polling_url to download the next PaymentRequest, it > seems we need a way to communicate an error code to the wallet, for example > if the server canceled the contract without the wallet knowing. Perhaps a > separate polling_status_url, with a corresponding ACK message to indicate > if the PaymentRequest is available. What do you think of that idea? > > > 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? > > 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. > > > Subscriptions are non ending by definition, but at any time the client > (through the wallet) or the merchant can decide to terminate the > subscriptions -- we
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hi Kevin, On Feb 11, 2014, at 2:00 AM, Kevin Greene wrote: > Figured I would have a crack at reviewing this since Mike is out for a bit. > It was great running into you guys at the bitcoin fair in SF! Small world :) Indeed! It was great meeting you! It's always nice to meet people in person... > I like how simple this is. You just give it an url to fetch the next payment > request and a date to fetch it. > > What should happen if the client tries to fetch the PaymentRequest early or > late? If the client tries to fetch too early, then the merchant will return a PaymentRequest with no output (there is nothing to pay yet). If it fetches too late, this is merchant specific. It could be that the service got discontinued -- extreme case -- or that there are now multiple PaymentRequest pending or that the merchant decided to aggregate those into one. In that scenario, it could lead to a case where the amount to pay goes beyond the contract and the wallet would refuse to make the recurring payment. > Does it become valid after some date and stay valid for some length of time? The protocol we sketched does not include (yet) an expiration date. At this point the contract is fairly minimal, and we could envision adding more parameters such as expiration date. So at this point the behavior would be dictated by the merchant. > Also, what should happen if the client tries to consume the same > PaymentRequest twice (or multiple times) during the same period? The merchant initiates the PaymentRequest and is in charge to make sure they match the invoices that the client should pay. On the client side, the wallet is responsible to verify that the contract is respected, so if a merchant were to issue multiple times the same PaymentRequest, the wallet would detect it goes beyond the bonds defined in the contract and would refuse to make the additional Payments. > I do not think daily/weekly/monthly is flexible enough. What do you think > about having a concrete start time and end time when the next PaymentRequest > will be valid? I agree that daily/weekly/monthly may not be flexible enough. However specifying a fixed date may be very tricky because in some cases a monthly subscription may start on a 31st of a month, and depending on the month, the due date will vary -- could be 30th, 28th, 29th, ... Also note that the frequency (daily/weekly/monthly) is not used as a polling interval, but is only used to verify the contract is respected. There are multiple viable options to specify that contract and ideally we could/should support multiple schemes; different merchants could use different schemes, and the client would decide wether or not he is ready to accept the terms that will later be enforced by the wallet. But of course all this flexibility goes against simplicity and so this is tradeoff... > This also prevents the wallet from having to remember when it last sent a > payment and getting skewed over time. Today, our current prototype is polling every day -- which is the lowest granularity we introduced -- and so there is no risk of getting skewed. > When a wallet hits the polling_url to download the next PaymentRequest, it > seems we need a way to communicate an error code to the wallet, for example > if the server canceled the contract without the wallet knowing. Perhaps a > separate polling_status_url, with a corresponding ACK message to indicate if > the PaymentRequest is available. What do you think of that idea? 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? > 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. Subscriptions are non ending by definition, but at any time the client (through the wallet) or the merchant can decide to terminate the subscriptions -- we did not yet implement cancellation in that prototype but we are planning to add it later this week. Think of your Netflix subscriptions, this is never ending (evergreen) until you decide to terminate it or Netflix does it (abuse, bills not paid,...) Thanks for taking a look! > > On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier > wrote: > Mike, Gavin, > > > We started to work on the merchant side to test the integration of our > prototype for the recurring payments. We modified the 'Payment Request > Generator' from Gavin to include a new check box 'set recurring'. We forked > the code and checked in our modification here: > https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3 > > We also found a few issues with the code diff that we sent yesterday for > bitcoinj and checked in the bug fixes in our fork-- so the diff sent > yesterday is slightly outdated. > > So at this point we have a
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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? -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hey guys, I'm on vacation now so won't be able to take a look until I'm back in a couple of weeks but the approach sounds reasonable based on your description. On 8 Feb 2014 08:28, "Stephane Brossier" wrote: > Mike and all, > > Pierre and I just committed a prototype implementation of the recurring > payment protocol using bitcoinj. You can find the diff on our fork: > > https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7 > > We did not write the server (merchant side), but wanted to have some > feedback before going deeper (merchant implementation and tests). We did > our best to build it on top of the existing BIP-0070 protocol-- only a few > additions in the messages, but no new calls and no new uri scheme. We > created a new package 'recurring' where most of the new code lives. > > At a high level: > > 1. Creation of the subscription: > > The initial handshake for creating the subscription is exactly similar to > the one for the payment protocol (PaymentRequest is used to provide the > contract) > > 2. Wallet can decide to poll the merchants for its active subscriptions. > > Here the flow is exactly similar to the payment protocol but the wallet > receives a callback to verify the payment matches the contract and should > go through. > > Please give us some feedback whenever you have the chance. In the meantime > we will start implementing the merchant side and test the code. > > Cheers! > > > > On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: > > That looks OK at a very high level. Things you probably want to think > about: > >- How to trigger it off the existing payment protocol (no new top >level messages or mime types or uri extensions please) >- Data structures to define the payment schedule >- Do you allow pre-submission of time locked transactions or not? > > I think as you prototype these things will become clearer. You could try > prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the > PaymentSession class). > > > > On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier > wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From what I have seen so far, there seems to be an agreement that this >> is a nice feature to add. We are pretty new to that community and so we >> don't know exactly what the process is, and in particular how we reach >> consensus via email. I am certainly open to follow 'the way' if there is >> one, but one solution would be to follow Mike's suggestion on providing a >> (prototype) implementation first and then defining/refining the BIP. Odinn >> also suggested a possible retribution for our time through crowd-sourcing >> which I am interested to pursue if that makes sense. We have quite some >> experience on the subscription side of things and while we are growing our >> knowledge on the Bitcoin technology (and ecosystem at large) we would >> benefit from: * some feedbacks on the high level proposal * additional >> requirements we might have missed So, below is a high level description of >> what we have in mind. If this sounds reasonable, we could start working on >> an implementation. I. Abstract --- This describes a protocol to >> enable recurring payments in bitcoins and can be seen as an extension of >> BIP-0070. The main goal here is to have the customer subscribe to a service >> of some kind (that is, agreeing on the terms of that subscription >> contract), and then have the wallet make recurring payments without any >> intervention from the customer as long as the payments match what the >> customer agreed on paying. An example of such service would be an online >> streaming website, to which a user pays a fixed recurring monthly fee to >> access videos (a.k.a. resources). Note that there is also usage based >> billing: for example, the user may need to purchase additional access for >> premium videos (overage charges). This type of billing is more complicated >> and there are many variations to it used in the industry (pre-paid, …). For >> the sake of discussion, we’ll focus on fixed recurring payments only, but >> we will keep usage in mind to make sure the protocol will be able to >> support it as well. II. Motivation -- Subscription based >> services have been growing in the past few years and so the intent it to >> make it possible for customers to pay in bitcoins. Bitcoin’s push model >> presents new advantages for the customer compared to traditional payment >> methods: the user has control over the subscription (for example, there is >> no need to call the merchant to explicitly cancel the credit card >> payments). It also opens the door to subscription management tools in >> wallets (e.g. Hive apps), which would give user an overview of what they >> are paying each month. III. Flow of >> Operations* >> >> >> >> >> * Creation of the subscription: - - - - - - - - - - - - - - - - - - - - - >> - 1. The customer clicks 'subsc
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Figured I would have a crack at reviewing this since Mike is out for a bit. It was great running into you guys at the bitcoin fair in SF! Small world :) I like how simple this is. You just give it an url to fetch the next payment request and a date to fetch it. What should happen if the client tries to fetch the PaymentRequest early or late? Does it become valid after some date and stay valid for some length of time? Also, what should happen if the client tries to consume the same PaymentRequest twice (or multiple times) during the same period? I do not think daily/weekly/monthly is flexible enough. What do you think about having a concrete start time and end time when the next PaymentRequest will be valid? This also prevents the wallet from having to remember when it last sent a payment and getting skewed over time. When a wallet hits the polling_url to download the next PaymentRequest, it seems we need a way to communicate an error code to the wallet, for example if the server canceled the contract without the wallet knowing. Perhaps a separate polling_status_url, with a corresponding ACK message to indicate if the PaymentRequest is available. What do you think of that idea? 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. On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier wrote: > Mike, Gavin, > > > We started to work on the merchant side to test the integration of our > prototype for the recurring payments. We modified the 'Payment Request > Generator' from Gavin to include a new check box 'set recurring'. We forked > the code and checked in our modification here: > https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3 > > We also found a few issues with the code diff that we sent yesterday for > bitcoinj and checked in the bug fixes in our fork-- so the diff sent > yesterday is slightly outdated. > > So at this point we have a working prototype for bitcoinj and we are > waiting for your feedbacks. We also started to look at integrating the > protocol in Kill Bill to check that what is proposed supports indeed the > business cases of a full recurring billing platform. > > Hope to hear from you guys soon! > > > On Feb 7, 2014, at 6:57 PM, Stephane Brossier > wrote: > > Mike and all, > > Pierre and I just committed a prototype implementation of the recurring > payment protocol using bitcoinj. You can find the diff on our fork: > > https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7 > > We did not write the server (merchant side), but wanted to have some > feedback before going deeper (merchant implementation and tests). We did > our best to build it on top of the existing BIP-0070 protocol-- only a few > additions in the messages, but no new calls and no new uri scheme. We > created a new package 'recurring' where most of the new code lives. > > At a high level: > > 1. Creation of the subscription: > > The initial handshake for creating the subscription is exactly similar to > the one for the payment protocol (PaymentRequest is used to provide the > contract) > > 2. Wallet can decide to poll the merchants for its active subscriptions. > > Here the flow is exactly similar to the payment protocol but the wallet > receives a callback to verify the payment matches the contract and should > go through. > > Please give us some feedback whenever you have the chance. In the meantime > we will start implementing the merchant side and test the code. > > Cheers! > > > > On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: > > That looks OK at a very high level. Things you probably want to think > about: > >- How to trigger it off the existing payment protocol (no new top >level messages or mime types or uri extensions please) >- Data structures to define the payment schedule >- Do you allow pre-submission of time locked transactions or not? > > I think as you prototype these things will become clearer. You could try > prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the > PaymentSession class). > > > > On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier > wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From what I have seen so far, there seems to be an agreement that this >> is a nice feature to add. We are pretty new to that community and so we >> don't know exactly what the process is, and in particular how we reach >> consensus via email. I am certainly open to follow 'the way' if there is >> one, but one solution would be to follow Mike's suggestion on providing a >> (prototype) implementation first and then defining/refining the BIP. Odinn >> also suggested a possible retribution for our time through crowd-sourcing >> which I am interested to pursue if that makes sense. We have quite some >> experience on the subscription side o
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Mike, Gavin, We started to work on the merchant side to test the integration of our prototype for the recurring payments. We modified the 'Payment Request Generator' from Gavin to include a new check box 'set recurring'. We forked the code and checked in our modification here: https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3 We also found a few issues with the code diff that we sent yesterday for bitcoinj and checked in the bug fixes in our fork-- so the diff sent yesterday is slightly outdated. So at this point we have a working prototype for bitcoinj and we are waiting for your feedbacks. We also started to look at integrating the protocol in Kill Bill to check that what is proposed supports indeed the business cases of a full recurring billing platform. Hope to hear from you guys soon! On Feb 7, 2014, at 6:57 PM, Stephane Brossier wrote: > Mike and all, > > Pierre and I just committed a prototype implementation of the recurring > payment protocol using bitcoinj. You can find the diff on our fork: > https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7 > > We did not write the server (merchant side), but wanted to have some feedback > before going deeper (merchant implementation and tests). We did our best to > build it on top of the existing BIP-0070 protocol-- only a few additions in > the messages, but no new calls and no new uri scheme. We created a new > package 'recurring' where most of the new code lives. > > At a high level: > > 1. Creation of the subscription: > > The initial handshake for creating the subscription is exactly similar to the > one for the payment protocol (PaymentRequest is used to provide the contract) > > 2. Wallet can decide to poll the merchants for its active subscriptions. > > Here the flow is exactly similar to the payment protocol but the wallet > receives a callback to verify the payment matches the contract and should go > through. > > Please give us some feedback whenever you have the chance. In the meantime we > will start implementing the merchant side and test the code. > > Cheers! > > > > On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: > >> That looks OK at a very high level. Things you probably want to think about: >> How to trigger it off the existing payment protocol (no new top level >> messages or mime types or uri extensions please) >> Data structures to define the payment schedule >> Do you allow pre-submission of time locked transactions or not? >> I think as you prototype these things will become clearer. You could try >> prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the >> PaymentSession class). >> >> >> >> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier >> wrote: >> From what I have seen so far, there seems to be an agreement that this is a >> nice feature to add. We are pretty new to that community and so we don't >> know exactly what the process is, and in particular how we reach consensus >> via email. I am certainly open to follow 'the way' if there is one, but one >> solution would be to follow Mike's suggestion on providing a (prototype) >> implementation first and then defining/refining the BIP. Odinn also >> suggested a possible retribution for our time through crowd-sourcing which I >> am interested to pursue if that makes sense. >> >> >> We have quite some experience on the subscription side of things and while >> we are growing our knowledge on the Bitcoin technology (and ecosystem at >> large) we would benefit from: >> * some feedbacks on the high level proposal >> * additional requirements we might have missed >> >> So, below is a high level description of what we have in mind. If this >> sounds reasonable, we could start working on an implementation. >> >> >> >> I. Abstract >> --- >> >> This describes a protocol to enable recurring payments in bitcoins and can >> be seen as an extension of BIP-0070. The main goal here is to have the >> customer subscribe to a service of some kind (that is, agreeing on the terms >> of that subscription contract), and then have the wallet make recurring >> payments without any intervention from the customer as long as the payments >> match what the customer agreed on paying. >> >> An example of such service would be an online streaming website, to which a >> user pays a fixed recurring monthly fee to access videos (a.k.a. resources). >> Note that there is also usage based billing: for example, the user may need >> to purchase additional access for premium videos (overage charges). This >> type of billing is more complicated and there are many variations to it used >> in the industry (pre-paid, …). For the sake of discussion, we’ll focus on >> fixed recurring payments only, but we will keep usage in mind to make sure >> the protocol will be able to support it as well. >> >> >> II. Motivation >> -- >>
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Mike and all, Pierre and I just committed a prototype implementation of the recurring payment protocol using bitcoinj. You can find the diff on our fork: https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7 We did not write the server (merchant side), but wanted to have some feedback before going deeper (merchant implementation and tests). We did our best to build it on top of the existing BIP-0070 protocol-- only a few additions in the messages, but no new calls and no new uri scheme. We created a new package 'recurring' where most of the new code lives. At a high level: 1. Creation of the subscription: The initial handshake for creating the subscription is exactly similar to the one for the payment protocol (PaymentRequest is used to provide the contract) 2. Wallet can decide to poll the merchants for its active subscriptions. Here the flow is exactly similar to the payment protocol but the wallet receives a callback to verify the payment matches the contract and should go through. Please give us some feedback whenever you have the chance. In the meantime we will start implementing the merchant side and test the code. Cheers! On Jan 31, 2014, at 10:13 AM, Mike Hearn wrote: > That looks OK at a very high level. Things you probably want to think about: > How to trigger it off the existing payment protocol (no new top level > messages or mime types or uri extensions please) > Data structures to define the payment schedule > Do you allow pre-submission of time locked transactions or not? > I think as you prototype these things will become clearer. You could try > prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the > PaymentSession class). > > > > On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier > wrote: > From what I have seen so far, there seems to be an agreement that this is a > nice feature to add. We are pretty new to that community and so we don't > know exactly what the process is, and in particular how we reach consensus > via email. I am certainly open to follow 'the way' if there is one, but one > solution would be to follow Mike's suggestion on providing a (prototype) > implementation first and then defining/refining the BIP. Odinn also suggested > a possible retribution for our time through crowd-sourcing which I am > interested to pursue if that makes sense. > > > We have quite some experience on the subscription side of things and while we > are growing our knowledge on the Bitcoin technology (and ecosystem at large) > we would benefit from: > * some feedbacks on the high level proposal > * additional requirements we might have missed > > So, below is a high level description of what we have in mind. If this sounds > reasonable, we could start working on an implementation. > > > > I. Abstract > --- > > This describes a protocol to enable recurring payments in bitcoins and can be > seen as an extension of BIP-0070. The main goal here is to have the customer > subscribe to a service of some kind (that is, agreeing on the terms of that > subscription contract), and then have the wallet make recurring payments > without any intervention from the customer as long as the payments match what > the customer agreed on paying. > > An example of such service would be an online streaming website, to which a > user pays a fixed recurring monthly fee to access videos (a.k.a. resources). > Note that there is also usage based billing: for example, the user may need > to purchase additional access for premium videos (overage charges). This type > of billing is more complicated and there are many variations to it used in > the industry (pre-paid, …). For the sake of discussion, we’ll focus on fixed > recurring payments only, but we will keep usage in mind to make sure the > protocol will be able to support it as well. > > > II. Motivation > -- > > Subscription based services have been growing in the past few years and so > the intent it to make it possible for customers to pay in bitcoins. > > Bitcoin’s push model presents new advantages for the customer compared to > traditional payment methods: the user has control over the subscription (for > example, there is no need to call the merchant to explicitly cancel the > credit card payments). It also opens the door to subscription management > tools in wallets (e.g. Hive apps), which would give user an overview of what > they are paying each month. > > > III. Flow of Operations > > > > Creation of the subscription: > - - - - - - - - - - - - - - - - - - - - - - > > 1. The customer clicks 'subscribe' -> A message is sent to the merchant. > 2. The merchant sends back a message to the wallet with the details of the > subscription such as the amount to be paid. In reality, there will be more > information but for the purpose of the prototype implementation this is
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
That looks OK at a very high level. Things you probably want to think about: - How to trigger it off the existing payment protocol (no new top level messages or mime types or uri extensions please) - Data structures to define the payment schedule - Do you allow pre-submission of time locked transactions or not? I think as you prototype these things will become clearer. You could try prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the PaymentSession class). On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier wrote: > > > > > > > > > > > > > > *From what I have seen so far, there seems to be an agreement that this is > a nice feature to add. We are pretty new to that community and so we don't > know exactly what the process is, and in particular how we reach consensus > via email. I am certainly open to follow 'the way' if there is one, but one > solution would be to follow Mike's suggestion on providing a (prototype) > implementation first and then defining/refining the BIP. Odinn also > suggested a possible retribution for our time through crowd-sourcing which > I am interested to pursue if that makes sense.We have quite some experience > on the subscription side of things and while we are growing our knowledge > on the Bitcoin technology (and ecosystem at large) we would benefit from:* > some feedbacks on the high level proposal* additional requirements we might > have missedSo, below is a high level description of what we have in mind. > If this sounds reasonable, we could start working on an implementation. I. > Abstract---This describes a protocol to enable recurring > payments in bitcoins and can be seen as an extension of BIP-0070. The main > goal here is to have the customer subscribe to a service of some kind (that > is, agreeing on the terms of that subscription contract), and then have the > wallet make recurring payments without any intervention from the customer > as long as the payments match what the customer agreed on paying.An example > of such service would be an online streaming website, to which a user pays > a fixed recurring monthly fee to access videos (a.k.a. resources). Note > that there is also usage based billing: for example, the user may need to > purchase additional access for premium videos (overage charges). This type > of billing is more complicated and there are many variations to it used in > the industry (pre-paid, …). For the sake of discussion, we’ll focus on > fixed recurring payments only, but we will keep usage in mind to make sure > the protocol will be able to support it as well.II. > Motivation--Subscription based services have been growing > in the past few years and so the intent it to make it possible for > customers to pay in bitcoins. Bitcoin’s push model presents new advantages > for the customer compared to traditional payment methods: the user has > control over the subscription (for example, there is no need to call the > merchant to explicitly cancel the credit card payments). It also opens the > door to subscription management tools in wallets (e.g. Hive apps), which > would give user an overview of what they are paying each month.III. Flow of > Operations* > > > > > *Creation of the subscription:- - - - - - - - - - - - - - - - - - - - - - > 1. The customer clicks 'subscribe' -> A message is sent to the merchant.2. > The merchant sends back a message to the wallet with the details of the > subscription such as the amount to be paid. In reality, there will be more > information but for the purpose of the prototype implementation this is > sufficient.3. The wallet prompts the customer for authorization.4. The > customer authorizes (or denies) it.5. The wallet sends the confirmation to > the merchant.6. The merchant confirms the subscription was created.Ongoing > payments:* > > *- - - - - - - - - - - - - - - -* > > > > > > > *From that time on and since Bitcoin is a 'push' model, the wallet is > responsible to poll the merchant for due payments associated with that > subscription. Note that the merchant could specify hints to the wallet on > when to poll (specific dates) or not during the registration of the > subscription.Note that we can't simply have the wallet push X bitcoins > every month: the user account on the merchant side may have gotten credits, > invoice adjustments, etc. since the last invoice, so the amount to pay for > a given billing period may be lower than the regular amount. It could even > be zero if the user decides to make a one-time payment to the merchant > directly using a different wallet. Hence, the wallet needs to get the > latest invoice balance to make sure how much it should pay. This also opens > the door for the support of overage charges.Quick note on the > implementation on the merchant side: an entitlement system is a piece of > logic on the merchant side which grants the user access to certain > resources depending
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
From what I have seen so far, there seems to be an agreement that this is a nice feature to add. We are pretty new to that community and so we don't know exactly what the process is, and in particular how we reach consensus via email. I am certainly open to follow 'the way' if there is one, but one solution would be to follow Mike's suggestion on providing a (prototype) implementation first and then defining/refining the BIP. Odinn also suggested a possible retribution for our time through crowd-sourcing which I am interested to pursue if that makes sense. We have quite some experience on the subscription side of things and while we are growing our knowledge on the Bitcoin technology (and ecosystem at large) we would benefit from: * some feedbacks on the high level proposal * additional requirements we might have missed So, below is a high level description of what we have in mind. If this sounds reasonable, we could start working on an implementation. I. Abstract --- This describes a protocol to enable recurring payments in bitcoins and can be seen as an extension of BIP-0070. The main goal here is to have the customer subscribe to a service of some kind (that is, agreeing on the terms of that subscription contract), and then have the wallet make recurring payments without any intervention from the customer as long as the payments match what the customer agreed on paying. An example of such service would be an online streaming website, to which a user pays a fixed recurring monthly fee to access videos (a.k.a. resources). Note that there is also usage based billing: for example, the user may need to purchase additional access for premium videos (overage charges). This type of billing is more complicated and there are many variations to it used in the industry (pre-paid, …). For the sake of discussion, we’ll focus on fixed recurring payments only, but we will keep usage in mind to make sure the protocol will be able to support it as well. II. Motivation -- Subscription based services have been growing in the past few years and so the intent it to make it possible for customers to pay in bitcoins. Bitcoin’s push model presents new advantages for the customer compared to traditional payment methods: the user has control over the subscription (for example, there is no need to call the merchant to explicitly cancel the credit card payments). It also opens the door to subscription management tools in wallets (e.g. Hive apps), which would give user an overview of what they are paying each month. III. Flow of Operations Creation of the subscription: - - - - - - - - - - - - - - - - - - - - - - 1. The customer clicks 'subscribe' -> A message is sent to the merchant. 2. The merchant sends back a message to the wallet with the details of the subscription such as the amount to be paid. In reality, there will be more information but for the purpose of the prototype implementation this is sufficient. 3. The wallet prompts the customer for authorization. 4. The customer authorizes (or denies) it. 5. The wallet sends the confirmation to the merchant. 6. The merchant confirms the subscription was created. Ongoing payments: - - - - - - - - - - - - - - - - From that time on and since Bitcoin is a 'push' model, the wallet is responsible to poll the merchant for due payments associated with that subscription. Note that the merchant could specify hints to the wallet on when to poll (specific dates) or not during the registration of the subscription. Note that we can't simply have the wallet push X bitcoins every month: the user account on the merchant side may have gotten credits, invoice adjustments, etc. since the last invoice, so the amount to pay for a given billing period may be lower than the regular amount. It could even be zero if the user decides to make a one-time payment to the merchant directly using a different wallet. Hence, the wallet needs to get the latest invoice balance to make sure how much it should pay. This also opens the door for the support of overage charges. Quick note on the implementation on the merchant side: an entitlement system is a piece of logic on the merchant side which grants the user access to certain resources depending on the account status (unpaid invoices, etc.). This goes often hand in hand with a dunning system, which progressively restricts access as the user's account is more and more overdue. Since wallets can be offline for an extended period of time, payments may be missed and lead to an overdue state (e.g. extra fees, service degraded). It is the responsibility of the customer to ensure the wallet is up often enough for payments to happen. In that recurring phase where the wallet polls the merchant, the wallet is responsible to check that payments match the subscription contract; that is, the amount, frequency of payments, … match what
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Let's keep fund raising off this mailing list, please. PS bounties don't work. On Tue, Jan 28, 2014 at 1:08 AM, Odinn Cyberguerrilla < odinn.cyberguerri...@riseup.net> wrote: > Greatly appreciate seeing this discussion occur. This is something that > potentially could be supported through a bounty - possibly a process BIP? > > Possibly related: https://gist.github.com/ABISprotocol/8515891 > > > Yes, recurring payments and subscriptions is a frequently-requested > > feature. It needs a new BIP. Here is an outline: > > > > The situation is somewhat analogous to HTML5 local storage. The remote > > (merchant) wants to initiate a persistent behavior. This is bitcoin, so > > we > > have a "push" model for payment, and the user has complete control. The > > merchant can, at most, send a "subscription request." The user is > > responsible for making on-time payments after that point. > > > > Centralized services like coinbase.com or blockchain.info will have an > > easy > > time of it. An automated program on their backend, sending payments as > > needed, is easy and direct. > > > > More inventive services might employ multisig transactions, generating > and > > signing one signature of a TX, then sending that TX to the human for > > further signing and publishing. A few competing vendors could offer bots > > that provide this signing service. > > > > Decentralized, standalone wallet clients will be somewhat troublesome. > We > > can store a local subscription request, and send recurring payments... > if > > the wallet app is running. If not, the user will be missing payments, > > that > > perhaps they intended to make (rent!). > > > > Each of these solutions can be cancelled at any time by the user. As > > such, > > a courtesy "subscription cancelled" message sent to the merchant is > > recommended. User controls the usage of their money at all times, the > way > > things should be. > > > > And finally, you do not want to make it /too easy/ to send money over and > > over again. From a human-interface perspective, a textual reminder to > > send > > money might be preferred over actual recurring payment automation: > > reminder > > email + manual spend inserts a bit of additional human thought and review > > into the process, with all that entails. > > > > -- > > Jeff Garzik > > Bitcoin core developer and open source evangelist > > BitPay, Inc. https://bitpay.com/ > > > -- > > WatchGuard Dimension instantly turns raw network data into actionable > > security intelligence. It gives you real-time visual feedback on key > > security issues and trends. Skip the complicated setup - simply import > > a virtual appliance and go from zero to informed in seconds. > > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
I think the right approach for this is to actually implement it and *then* propose a BIP. There are so many possible features we could add to the payment protocol, any other approach would rapidly turn into lots of people deciding to do the "fun bits" and often leaving others doing the hard work with difficult or unworkable specs. For instance, if you try to implement this, you would rapidly discover that it probably makes more sense to do this as an additional set of fields in PaymentDetails rather than a new message type entirely. A new top level message type would in turn require new MIME types, URI extensions and so on. That doesn't make any sense. Once you decide to extend PaymentDetails, the next discovery would be that it probably makes sense to try and solve the problem of address re-use for recurring payments first, before speccing out time intervals and so on. That's a separate BIP. I'm all for adding recurring payments as a feature, that's what the protocol is there for. But I'd like to see future protocol extension requests come after at least one working implementation has been made . On Tue, Jan 28, 2014 at 3:36 AM, Stephane Brossier wrote: > Hi, > > [I sent this email 2 days ago prior my registration to the mailing list; > please forgive me if this is a duplicate] > > I would like to propose an extension to the Payment Protocol (bip-0070) to > address the case of recurring payments in Bitcoin -- new bip or > modification of bip-0070. > > There has been a lot of growth in the last few years in the 'subscription > economy' with many new companies embracing that model -- online video, > gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a > mainstream currency (hence bip-0070), and so the next logical step would be > to define a protocol to address that need. > > We have been working in the past few years on an open-source billing > platform (http://kill-bill.org/), and recently came with a prototype to > do recurring billing in Bitcoin (see > http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and > http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/ > ). > > > The work flow would look similar to the one from bip-0070. There would > need to be some additions; the flow could be summarized as follow: > > 0. Click: 'Subscribe Now' > 1. Wallet would get a RecurringPaymentRequestAuth which describes the > nature of the future recurring payments > 2. The Customer would get prompted from the wallet to authorize it. > 3. The wallet would then poll the Merchant server (startup time, and/or > well defined frequency) and potentially merchant would start issuing a > PaymentRequest); the role of the wallet is to ensure that PaymentRequest is > within the bounds of what was accepted by the customer-- amount, > frequency,.. If it is, then it would make the Payment the same way it works > for bip-0070 > > Is that something that the community would be interested in? We could > provide more details about the protocol we have in mind (messages and > flow), and also provide an implementation with bitcoinj as a wallet and > Kill Bill as a merchant server. > > Le me know what you think. > > Stéphane > > > -- > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Greatly appreciate seeing this discussion occur. This is something that potentially could be supported through a bounty - possibly a process BIP? Possibly related: https://gist.github.com/ABISprotocol/8515891 > Yes, recurring payments and subscriptions is a frequently-requested > feature. It needs a new BIP. Here is an outline: > > The situation is somewhat analogous to HTML5 local storage. The remote > (merchant) wants to initiate a persistent behavior. This is bitcoin, so > we > have a "push" model for payment, and the user has complete control. The > merchant can, at most, send a "subscription request." The user is > responsible for making on-time payments after that point. > > Centralized services like coinbase.com or blockchain.info will have an > easy > time of it. An automated program on their backend, sending payments as > needed, is easy and direct. > > More inventive services might employ multisig transactions, generating and > signing one signature of a TX, then sending that TX to the human for > further signing and publishing. A few competing vendors could offer bots > that provide this signing service. > > Decentralized, standalone wallet clients will be somewhat troublesome. We > can store a local subscription request, and send recurring payments... if > the wallet app is running. If not, the user will be missing payments, > that > perhaps they intended to make (rent!). > > Each of these solutions can be cancelled at any time by the user. As > such, > a courtesy "subscription cancelled" message sent to the merchant is > recommended. User controls the usage of their money at all times, the way > things should be. > > And finally, you do not want to make it /too easy/ to send money over and > over again. From a human-interface perspective, a textual reminder to > send > money might be preferred over actual recurring payment automation: > reminder > email + manual spend inserts a bit of additional human thought and review > into the process, with all that entails. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > -- > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
It could be useful to schedule x payments for y amount every z time period, but you'd want to be able to pause or cancel at any time. If you want the merchant to be able to request a series of payments like a subscription, the merchant might also be able to request that the subscription be paused or cancelled as well. - - - - - - - - - - - - - - - - - - - Richard Kohl - rich...@pikapay.com Twitter: @generalseven Phone: +31 6 284 00112 PikaPay: Send Bitcoins with Twitter -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Yes, recurring payments and subscriptions is a frequently-requested feature. It needs a new BIP. Here is an outline: The situation is somewhat analogous to HTML5 local storage. The remote (merchant) wants to initiate a persistent behavior. This is bitcoin, so we have a "push" model for payment, and the user has complete control. The merchant can, at most, send a "subscription request." The user is responsible for making on-time payments after that point. Centralized services like coinbase.com or blockchain.info will have an easy time of it. An automated program on their backend, sending payments as needed, is easy and direct. More inventive services might employ multisig transactions, generating and signing one signature of a TX, then sending that TX to the human for further signing and publishing. A few competing vendors could offer bots that provide this signing service. Decentralized, standalone wallet clients will be somewhat troublesome. We can store a local subscription request, and send recurring payments... if the wallet app is running. If not, the user will be missing payments, that perhaps they intended to make (rent!). Each of these solutions can be cancelled at any time by the user. As such, a courtesy "subscription cancelled" message sent to the merchant is recommended. User controls the usage of their money at all times, the way things should be. And finally, you do not want to make it /too easy/ to send money over and over again. From a human-interface perspective, a textual reminder to send money might be preferred over actual recurring payment automation: reminder email + manual spend inserts a bit of additional human thought and review into the process, with all that entails. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Yes, recurring payments and subscriptions is a frequently-requested feature. It needs a new BIP. Here is an outline: The situation is somewhat analogous to HTML5 local storage. The remote (merchant) wants to initiate a persistent behavior. Note: This is ONE -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
+1 to the idea of recurring payment requests. Perhaps one way to realize this would be to add an optional URL to the PaymentRequest object where the next PaymentRequest can be fetched and the date at which the merchant expects the next payment. On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier wrote: > Hi, > > [I sent this email 2 days ago prior my registration to the mailing list; > please forgive me if this is a duplicate] > > I would like to propose an extension to the Payment Protocol (bip-0070) to > address the case of recurring payments in Bitcoin -- new bip or > modification of bip-0070. > > There has been a lot of growth in the last few years in the 'subscription > economy' with many new companies embracing that model -- online video, > gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a > mainstream currency (hence bip-0070), and so the next logical step would be > to define a protocol to address that need. > > We have been working in the past few years on an open-source billing > platform (http://kill-bill.org/), and recently came with a prototype to > do recurring billing in Bitcoin (see > http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and > http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/ > ). > > > The work flow would look similar to the one from bip-0070. There would > need to be some additions; the flow could be summarized as follow: > > 0. Click: 'Subscribe Now' > 1. Wallet would get a RecurringPaymentRequestAuth which describes the > nature of the future recurring payments > 2. The Customer would get prompted from the wallet to authorize it. > 3. The wallet would then poll the Merchant server (startup time, and/or > well defined frequency) and potentially merchant would start issuing a > PaymentRequest); the role of the wallet is to ensure that PaymentRequest is > within the bounds of what was accepted by the customer-- amount, > frequency,.. If it is, then it would make the Payment the same way it works > for bip-0070 > > Is that something that the community would be interested in? We could > provide more details about the protocol we have in mind (messages and > flow), and also provide an implementation with bitcoinj as a wallet and > Kill Bill as a merchant server. > > Le me know what you think. > > Stéphane > > > -- > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hi, [I sent this email 2 days ago prior my registration to the mailing list; please forgive me if this is a duplicate] I would like to propose an extension to the Payment Protocol (bip-0070) to address the case of recurring payments in Bitcoin -- new bip or modification of bip-0070. There has been a lot of growth in the last few years in the 'subscription economy' with many new companies embracing that model -- online video, gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a mainstream currency (hence bip-0070), and so the next logical step would be to define a protocol to address that need. We have been working in the past few years on an open-source billing platform (http://kill-bill.org/), and recently came with a prototype to do recurring billing in Bitcoin (see http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/). The work flow would look similar to the one from bip-0070. There would need to be some additions; the flow could be summarized as follow: 0. Click: 'Subscribe Now' 1. Wallet would get a RecurringPaymentRequestAuth which describes the nature of the future recurring payments 2. The Customer would get prompted from the wallet to authorize it. 3. The wallet would then poll the Merchant server (startup time, and/or well defined frequency) and potentially merchant would start issuing a PaymentRequest); the role of the wallet is to ensure that PaymentRequest is within the bounds of what was accepted by the customer-- amount, frequency,.. If it is, then it would make the Payment the same way it works for bip-0070 Is that something that the community would be interested in? We could provide more details about the protocol we have in mind (messages and flow), and also provide an implementation with bitcoinj as a wallet and Kill Bill as a merchant server. Le me know what you think. Stéphane-- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
