From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WIblN-0000y6-F1 for bitcoin-development@lists.sourceforge.net; Wed, 26 Feb 2014 10:30:53 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.174 as permitted sender) client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f174.google.com; Received: from mail-ob0-f174.google.com ([209.85.214.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WIblL-0003tu-SP for bitcoin-development@lists.sourceforge.net; Wed, 26 Feb 2014 10:30:53 +0000 Received: by mail-ob0-f174.google.com with SMTP id uy5so559860obc.33 for ; Wed, 26 Feb 2014 02:30:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.37.99 with SMTP id x3mr917892oej.61.1393410646463; Wed, 26 Feb 2014 02:30:46 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Wed, 26 Feb 2014 02:30:46 -0800 (PST) In-Reply-To: References: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org> <81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org> Date: Wed, 26 Feb 2014 16:00:46 +0530 X-Google-Sender-Auth: _IQKcuHE2AvCrawwga5EKY5SQx4 Message-ID: From: Mike Hearn To: Stephane Brossier Content-Type: multipart/alternative; boundary=089e011762799bdbf104f34cb22b X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WIblL-0003tu-SP Cc: Bitcoin Dev , Pierre-Alexandre Meyer Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 10:30:54 -0000 --089e011762799bdbf104f34cb22b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 firs= t > 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 merchan= t > 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 accepte= d > by the customer).I think it would help to explain how we ended up with th= e > 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 b= e > paid. In our case the exact amount may not be completely known in advance > -- for e.g taxes, shipping, pro-rations, =E2=80=A6 and so we decided to i= ntroduce > first a max amount per payment, and also a max amount per period. It is u= p > to the merchant to decide whether to specify none, any or both bounds (ma= x > 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 th= e > 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 th= at > 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 (ideal= ly > each day when it is up) to understand if there is something pending. In t= he > 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 a= re > a lot of complex scenarios in the billing space, and having the wallet po= ll > 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 giv= e > 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 beyon= d > 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=E2=80=99t predict (this scenario is often referred to as = usage > billing with Prepay Credits and Top-up, where the customer pays in advanc= e > 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 digit= al > 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 =3D 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 hig= h? > 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 "requir= ed" > can hurt backwards compatibility. Because it will be expressed using a > languages underlying enum type, if there's a new enum member added lat= er > old software that attempts to deserialize this will throw exceptions > because the new "unknown" member would be unrepresentable in the old m= odel. > Making the field optional avoids this problem (it will be treated as > missing instead) but means software needs to be written to know what t= o do > when it can't read the enum value / sees enum values from the future. > > > > I hope the explanation above answers the questions. > > > 1. I assume the amounts are specified in terms of satoshi, and > timestamps are UNIX time, but better to make that explicit. > > > > Yes. > > > 1. Seems there's an implicit value constraint that max_payment_amount > <=3D max_payment_per_period. What happens if that constraint is violat= ed? > 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 th= e > 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 such violation and if so, makes the paymen= t. > > > 1. What's the "merchant ID" namespace thing about? What's it for? What > happens if I set my competitors merchant ID there? > > > I agree, we can easily get rid of it. > > > 1. What's the "subscription ID"? Is this stuff not > duplicative/redundant with the existing merchant_data field? > > > In an ideal world the merchant should return unique subscriptionId (UUID > for instance). That subscriptionId is used in the code to identify the > contracts associated with the subscription. The merchant_data if i > understand correctly the payment protocol is opaque from the client point > of view, so it cannot be used by the client for that purpose. > > > 1. 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 z= ero > contracts included the data should be ignored, or an error thrown and = the > entire payment request rejected? Which should it be? > > > > > There are many example where that could happen; for instance if you > subscribe to a service, then later decide to downgrade to a lower produc= t. > The merchant may decide to only let you downgrade at the end of your paid > period-- to avoid generating extra credit-- and in that situation you end > up with two contracts: One for the current product you are in and one for > the future product you will end up on when the downgrade becomes effectiv= e. > > > > 1. 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 mo= nth > would the payment occur? > > > > As outlined above in the introduction, the protocol is designed in such a > way that the wallet does not have to know what is the exact date when > payment should occur, but instead polls the merchant for pending payments= . > There are many situations when specifying an exact payment date is not an > option so that flexibility is essential. A simple example would be for a > customer who started subscribing on the 31th of a month. Since there will > be months with 28/29/30 days, the payment date would change depending on > the month. > > > > > > 1. 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 c= hange > it - long comments are good and putting them above the field definitio= ns > encourages people to write enough detail without being put off by line > length constraints > > > > Fine. > > > I think the next step would be to talk to BitPay/get Jeff+Stephen involve= d > because I know they have customers that really want recurring payments, a= nd > 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. > > > > We are totally open to receive feedbacks from them.. How do we bring them > in the discussion? > > > I have some other comments about the bitcoinj implementation specifically > - for instance, we don't have a "wallet directory" concept: everything go= es > 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 likel= y > 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. > > > Ok that makes sense. > > > BIP 70 is indeed implemented in Bitcoin Core on the C++ side, so that > isn't a concern. It could be done there too. > > > Great to know. > > > > --089e011762799bdbf104f34cb22b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 ra= tionale for the design and how you use it is made clear to developers.

I've CCd Jeff and Stephen on this thread, so they c= an 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 nee= ds.


On Wed, Feb 2= 6, 2014 at 9:23 AM, Stephane Brossier <stephane@kill-bill.org>= wrote:
=
Hi Mike, Jeremy, Drak,

  • The contract n= egotiation; when the user first subscribes, it is prompted by a contract th= at 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 recu= rring payment protocol. The wallet will poll the merchant and issue payment= s as they are requested by the merchant as long as they stay within the bou= nds 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 -- fo= r e.g taxes, shipping, pro-rations, =E2=80=A6 and so we decided to introduc= e first a max amount per payment, and also a max amount per period. It is u= p to the merchant to decide whether to specify none, any or both bounds (ma= x amount per payment and max amount per period). By specifying both, the co= ntract is tighter and the client would feel safer to accept it. In the extr= eme 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. =C2=A0=C2=A0=


    <= div>
    See answers in your questions inlined be= low:
    I have the following comments:
    1. There's no need to serialize RecurringPaymentDetails as by= tes here. It's done that way outside of PaymentDetails in order to supp= ort digital signatures over protobufs that may have extensions the wallet a= pp isn't aware of, but it's a pain and inside PaymentDetails (and t= herefore for most extensions) it shouldn't be necessary. So you can jus= t use "optional RecurringPamentDetails recurring_payments =3D 8;"=


    OK, we'= ;ll fix it.


    1. There's only 4 possibiliti= es here for recurrences. That seems rather restrictive. Is the cost of bein= g 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 o= f protobufs to be aware of is that making an enum field "required"= ; can hurt backwards compatibility. Because it will be expressed using a la= nguages underlying enum type, if there's a new enum member added later = old software that attempts to deserialize this will throw exceptions becaus= e the new "unknown" member would be unrepresentable in the old mo= del. Making the field optional avoids this problem (it will be treated as m= issing instead) but means software needs to be written to know what to do w= hen it can't read the enum value / sees enum values from the future.

    I hope the= explanation above answers the questions.

    1. I assume the am= ounts are specified in terms of satoshi, and timestamps are UNIX time, but = better to make that explicit.


    Yes.
    =

    1. Seems there's an implicit value constraint that max_paymen= t_amount <=3D max_payment_per_period. What happens if that constraint is= violated? Best to document that.


    As explained ab= ove, contract would define none, 1 or both conditions. =C2=A0First the merc= hant 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 such violation and if so, makes the payment.

    1. What's the "merchant ID" namespa= ce thing about? What's it for? What happens if I set my competitors mer= chant ID there?

    I agree, we can easily g= et rid of it.

    1. What's the "subscription ID&q= uot;? Is this stuff not duplicative/redundant with the existing merchant_da= ta field?

    In an ideal wo= rld the merchant should return unique subscriptionId (UUID for instance). T= hat subscriptionId is used in the code to identify the contracts associated= with the subscription. The merchant_data if i understand correctly the pay= ment protocol is opaque from the client point of view, so it cannot be used= by the client for that purpose.=C2=A0
    1. In what situations would you have >1 contract per payment req= uest? I'm not sure I understand why it's repeated. Presumably if th= ere are zero contracts included the data should be ignored, or an error thr= own and the entire payment request rejected? Which should it be?



    =
    There are many example where that could =C2=A0happen; for instance if = you subscribe to a service, =C2=A0then later decide to downgrade to a lower= product. The merchant may decide to only let you downgrade at the end of y= our paid period-- to avoid generating extra credit-- and in that situation = you end up with two contracts: One for the current product you are in and o= ne for the future product you will end up on when the downgrade becomes eff= ective.


    1. It's unclear to me given such a contract wh= en the payment should actually occur. For instance if it's "monthl= y" then what day in the month would the payment occur?


    As outline= d above in the introduction, the protocol is designed in such a way that th= e wallet does not have to know what is the exact date when payment should o= ccur, but instead polls the merchant for pending payments. There are many s= ituations when specifying an exact payment date is not an option so that fl= exibility is essential. A simple example would be for a customer who starte= d subscribing on the 31th of a month. Since there will be months with 28/29= /30 days, the payment date would change depending on the month.




    1. 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 wri= te enough detail without being put off by line length constraints


    Fine= .


    I think the next step would be to talk to BitPay/get Jeff+St= ephen involved because I know they have customers that really want recurrin= g payments, and those guys will have a clearer idea of customer requirement= s 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 real= ly know much about the underlying business processes.


    We are totally = open to receive feedbacks from them.. How do we bring them in the discussio= n?


    I have some other comments about the bitcoinj implement= ation specifically - for instance, we don't have a "wallet directo= ry" concept: everything goes into the wallet file. So we'll need t= o think about how to structure the code to allow that. Also, just using a b= ackground polling thread is likely not flexible enough, as on some platform= s 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 th= at over on the bitcoinj list specifically. Let's keep this thread for t= he general protocol design.

    Ok that makes sense.


    BIP 70 is indeed implemented in B= itcoin Core on the C++ side, so that isn't a concern. It could be done = there too.


    Great to know.

    <= br>


    --089e011762799bdbf104f34cb22b--