Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDTRm-0000Pt-F3 for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 06:37:26 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.175 as permitted sender) client-ip=209.85.160.175; envelope-from=kgreenek@gmail.com; helo=mail-yk0-f175.google.com; Received: from mail-yk0-f175.google.com ([209.85.160.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WDTRl-0005o8-PK for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 06:37:26 +0000 Received: by mail-yk0-f175.google.com with SMTP id 131so14092807ykp.6 for ; Tue, 11 Feb 2014 22:37:20 -0800 (PST) X-Received: by 10.236.32.36 with SMTP id n24mr38322yha.116.1392187040295; Tue, 11 Feb 2014 22:37:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.94.66 with HTTP; Tue, 11 Feb 2014 22:37:00 -0800 (PST) In-Reply-To: References: <0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org> From: Kevin Greene Date: Tue, 11 Feb 2014 22:37:00 -0800 Message-ID: To: Stephane Brossier Content-Type: multipart/alternative; boundary=001a11c1c2d8ff6faf04f22fcd55 X-Spam-Score: -0.6 (/) 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 (kgreenek[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WDTRl-0005o8-PK 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: Wed, 12 Feb 2014 06:37:26 -0000 --001a11c1c2d8ff6faf04f22fcd55 Content-Type: text/plain; charset=ISO-8859-1 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? --001a11c1c2d8ff6faf04f22fcd55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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, cont= inuing to think about this even more, maybe the simple memo field along wit= h an empty set of outputs is enough already.

In bitcoinj, right now the code will throw a Paym= entRequestException.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 ou= tputs and a payment request that had some invalid output(s).

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