From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WHzt9-0003lP-4Q for bitcoin-development@lists.sourceforge.net; Mon, 24 Feb 2014 18:04:23 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of kill-bill.org designates 209.85.160.45 as permitted sender) client-ip=209.85.160.45; envelope-from=stephane@kill-bill.org; helo=mail-pb0-f45.google.com; Received: from mail-pb0-f45.google.com ([209.85.160.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WHzt7-0007mJ-JE for bitcoin-development@lists.sourceforge.net; Mon, 24 Feb 2014 18:04:23 +0000 Received: by mail-pb0-f45.google.com with SMTP id un15so6871414pbc.32 for ; Mon, 24 Feb 2014 10:04:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6Zq3gn2o689ybwXM/2jN7uBh6ojwzLpsrbbXq2aXBKc=; b=ZV9jridET6rdBl0V0JK7RZIvzXPMDk2cxraPQ+GqyHEkP0AfGtrB0d1/lXSQYRdoQ2 AbGlsZ0HcaGn1Xsjnip6hGX9eV5v6BAcpfuBCrxSBw0lZMODgMFCJ6/GTb1jucJ6V/46 Qrd+BGlJiMXkJUa9lSXOJqxYg3x0LnZ3RTNf9fADUcekNNcU3KJ6p3ZE7yZn1yg3ln/7 XUFoFEBp8wVgWtN7uh4hclS4mlFuRU2l2M9Vdz1+UlZleZP6tlDllrKp5JrBJzRikf5x iZmxcENj/3Y7usqDe/DP4LqpaMNQpr+eq4Mfp2RCD4eGRZlreGjV//XAyrCUKa3BXTPW YeKg== X-Gm-Message-State: ALoCoQkOkutOQLbP2+D2WEAu8iN/JGBRBezvQOscaoknSDIROgfijnopS6UjFwcuDPbEGKVpLtHv X-Received: by 10.68.242.68 with SMTP id wo4mr1292044pbc.32.1393265055660; Mon, 24 Feb 2014 10:04:15 -0800 (PST) Received: from [192.168.1.107] (adsl-71-146-11-193.dsl.pltn13.sbcglobal.net. [71.146.11.193]) by mx.google.com with ESMTPSA id ei4sm2097534pbb.42.2014.02.24.10.04.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 10:04:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D5FC4DB-08FD-469A-90F9-DACB05381773" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Stephane Brossier In-Reply-To: <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org> Date: Mon, 24 Feb 2014 10:04:21 -0800 Message-Id: <81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org> References: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org> To: Mike Hearn X-Mailer: Apple Mail (2.1510) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WHzt7-0007mJ-JE Cc: Pierre-Alexandre Meyer , Bitcoin Dev 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: Mon, 24 Feb 2014 18:04:23 -0000 --Apple-Mail=_7D5FC4DB-08FD-469A-90F9-DACB05381773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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,=20 * 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, >=20 > 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. >=20 > We wanted to follow up on a few pervious points you raised: >=20 > > However, continuing to think about this even more, maybe the simple = memo field along with an empty set of outputs is enough already. >=20 > =46rom 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)? >=20 > > 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. >=20 > We extended our RecurringPaymentDetails message to support this use = case, as it solves the problem of subscription changes and cancellations = for free. >=20 > 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. >=20 > 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. >=20 > All of this contract metadata is returned to the wallet so the user = can make an informed decision. >=20 >=20 > Thanks for your feedbacks! >=20 > S. >=20 >=20 > On Feb 11, 2014, at 10:37 PM, Kevin Greene wrote: >=20 >> Sending this again and truncating since apparently the message body = was too long. >>=20 >> Thanks for humoring my questions! >>=20 >> >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? >>=20 >> 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. >>=20 >> 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). >>=20 >> Question to everyone: >> How does bitcoin-qt handle a PaymentRequest with no outputs? >=20 --Apple-Mail=_7D5FC4DB-08FD-469A-90F9-DACB05381773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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/kil= lbill/paymentrequest). I think it does not make much sense from our = side to invest more efforts until we hear some = feedbacks.

Once we agree/integrate any = feedbacks you guys may have-- a proposal for next steps would = be:
* Turn that into a actual BIP so as to detail how = that works, 
* Write some more serious unit = tests
* Merge back code into bitconj = trunk

Down the line write the C++ code, but of = course that would assume BIP0070 is also implemented in C++ as we rely = on it.

I understand you guys may have more = important matters to solve these days with the recent malleability = issue, but i want to make it clear that we are waiting for feedbacks to = make additional = progress.

Thanks!

S.




On Feb 14, 2014, at 12:28 PM, Stephane Brossier <stephane@kill-bill.org> = wrote:

Upon cancellation of the bronze = plan, the end date of the contract will be updated and polling will stop = eventually.

All of this contract metadata is = returned to the wallet so the user can make an informed = decision.


Thanks for your = feedbacks!

S.


=
On Feb 11, 2014, at 10:37 PM, Kevin Greene <kgreenek@gmail.com> = wrote:

Sending this again and truncating since = apparently the message body was too long.

Thanks for = humoring my questions!

>I think reporting such errors to the = wallet would make complete sense. However i am not clear why we would a = separate url for that?

Hmm, thinking = about this more, adding a simple status_code in PaymentRequest would be = a much easier way to achieve this. However, continuing to think about = this even more, maybe the simple memo field along with an empty set of = outputs is enough already.

In bitcoinj, right = now the code will throw a PaymentRequestException.InvalidOutputs = exception if the set of outputs is empty with a message of "No Outputs". = Because of that, there isn't a good way to tell the difference between a = payment request that had no outputs and a payment request that had some = invalid output(s).

Question to = everyone:
How does bitcoin-qt handle a PaymentRequest with no = outputs?


= --Apple-Mail=_7D5FC4DB-08FD-469A-90F9-DACB05381773--