public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Date: Tue, 25 Feb 2014 14:06:20 -0500	[thread overview]
Message-ID: <CANOOu=-uijS7TxYcC+MD_OPYbZ4BFg-Cy6qOHv5u=TiUq2JenQ@mail.gmail.com> (raw)
In-Reply-To: <CANAnSg3LF6m9u-MV8XiiomMPrbihJh7hm5o=menOWY71bLkdAg@mail.gmail.com>

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 <drak@zikula.org> 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 <mike@plan99.net> 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 "monthly" then what day in the month would the
>> payment occur?
>>
>> 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 protocol design.
>>
>> BIP 70 is indeed implemented in Bitcoin Core on the C++ side, so that
>> isn't a concern. It could be done there too.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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
>



  parent reply	other threads:[~2014-02-25 19:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28  2:36 [Bitcoin-development] Extension for BIP-0070 to support recurring payments Stephane Brossier
2014-01-28  3:58 ` Kevin Greene
2014-01-28  4:29 ` Jeff Garzik
2014-01-28  4:43 ` Jeff Garzik
2014-01-28  5:07   ` PikaPay
2014-01-28  6:08   ` Odinn Cyberguerrilla
2014-01-28  6:48     ` Jeff Garzik
2014-01-28  6:34 ` Mike Hearn
2014-01-29  2:47   ` Stephane Brossier
2014-01-31 18:13     ` Mike Hearn
2014-02-08  2:57       ` Stephane Brossier
2014-02-09  2:48         ` Stephane Brossier
2014-02-11 10:00           ` Kevin Greene
2014-02-11 18:01             ` Stephane Brossier
2014-02-12  6:32               ` Kevin Greene
2014-02-12  6:37                 ` Kevin Greene
2014-02-14 20:28                   ` Stephane Brossier
2014-02-24 18:04                     ` Stephane Brossier
2014-02-25 16:29                       ` Mike Hearn
2014-02-25 18:40                         ` Drak
2014-02-25 19:03                           ` Jeremy Spilman
2014-02-25 19:06                           ` Christophe Biocca [this message]
2014-02-26  3:53                         ` Stephane Brossier
2014-02-26 10:30                           ` Mike Hearn
2014-02-11 16:24         ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANOOu=-uijS7TxYcC+MD_OPYbZ4BFg-Cy6qOHv5u=TiUq2JenQ@mail.gmail.com' \
    --to=christophe.biocca@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox