Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WEPND-0004d7-Ha for bitcoin-development@lists.sourceforge.net; Fri, 14 Feb 2014 20:28:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of kill-bill.org designates 209.85.220.51 as permitted sender) client-ip=209.85.220.51; envelope-from=stephane@kill-bill.org; helo=mail-pa0-f51.google.com; Received: from mail-pa0-f51.google.com ([209.85.220.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WEPNC-0001im-E8 for bitcoin-development@lists.sourceforge.net; Fri, 14 Feb 2014 20:28:35 +0000 Received: by mail-pa0-f51.google.com with SMTP id ld10so12814113pab.38 for ; Fri, 14 Feb 2014 12:28:28 -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=Fcd/m5trMbC0eSx5R1zhOsQtpd1jfV9ISrMogdNJcqo=; b=J5ULrHpxQScs0mWMbCsWxfznmKR8++JCzf6B7jfUxOaI35bppRsSBkYJ4YI3UkPEdD jK2kfL6R5unv3guIkL+YyEDoH+VYJptsTT0wGAjSNUpG5wg+crusyBfhTBaVc9XBiXT8 H1rpWJT3weu8Ri/IvayN7vyDJOA0OV9x4kwmLypQCP3UwazoDIWivpIhG1q3lCsVRLFS 12S0TBtwQyb1fpN99+g7mRRMHz6uxvugtMUQT4tmf+F0GJodrosjxaCXlOGM0opoo95g XoLxKsl4U1y5WcUmyx1/CpnxDeChSM1I11AeTa8uILzoAJvKLsh9Dm2bH94wB/6F5dIo Svlg== X-Gm-Message-State: ALoCoQkNhkQqSIWBSCUubRSG8WpUUjL+5Svh5yLFEpTtv3IFe7r2JCgoxEakp9TVw9qWAjOTbyH2 X-Received: by 10.66.121.68 with SMTP id li4mr11429400pab.33.1392409708452; Fri, 14 Feb 2014 12:28:28 -0800 (PST) Received: from [192.168.1.104] (adsl-71-146-11-192.dsl.pltn13.sbcglobal.net. [71.146.11.192]) by mx.google.com with ESMTPSA id iq10sm20196216pbc.14.2014.02.14.12.28.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 12:28:27 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_347698E4-F605-4008-8465-350BC552A927" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Stephane Brossier In-Reply-To: Date: Fri, 14 Feb 2014 12:28:24 -0800 Message-Id: <5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org> References:

<0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org>

To: Kevin Greene 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: 1WEPNC-0001im-E8 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: Fri, 14 Feb 2014 20:28:35 -0000 --Apple-Mail=_347698E4-F605-4008-8465-350BC552A927 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. =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)? > 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. >=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? --Apple-Mail=_347698E4-F605-4008-8465-350BC552A927 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

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=_347698E4-F605-4008-8465-350BC552A927--