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 1V7A6G-00070e-Nt for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 20:12:52 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V7A6E-0002pl-Sa for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 20:12:52 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r77KCWl1044340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 21:12:37 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r77KCWwe044339; Wed, 7 Aug 2013 21:12:32 +0100 (BST) (envelope-from roy) Date: Wed, 7 Aug 2013 21:12:32 +0100 From: Roy Badami To: E willbefull Message-ID: <20130807201231.GM16713@giles.gnomon.org.uk> References: <20130731084538.GL16713@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.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_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V7A6E-0002pl-Sa Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 20:12:52 -0000 On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote: > I think it's important to expect PaymentRequest-only bitcoin URIs in the > future. Some types of payments (exotic transactions) may not make sense to > have a single fallback address. Or, a page with a bitcoin URI link may be > relying on a separate service provider to assemble the transaction. Also: * There may be a desire to minimize the URL length when used in a QR code * Some applications might specifically require some of the features of the payment protocol - e.g. it may be a requirement that a print-media QR code cannot be used after a cut-off date, or a vendor may have a specific requirement not to accept payments without a refund address There are pros and cons, but it's not clear to me that the benefits of enforced backward compatibility outweigh the benefits of allowing application designers to innovate as they see fit. roy