summaryrefslogtreecommitdiff
path: root/12/803aa47d2d342e2394613c00ee416ef5ac920e
blob: 762b800350185feb30816d9bc7e63f45a04ee077 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
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 <roy@gnomon.org.uk>) 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 <roy@gnomon.org.uk>
To: E willbefull <ewillbefull@gmail.com>
Message-ID: <20130807201231.GM16713@giles.gnomon.org.uk>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
	<20130731084538.GL16713@giles.gnomon.org.uk>
	<CABsx9T3Xvnw2H6awgnT7mr-HzJOqCp_nOVM57BD-B9mY4R43aQ@mail.gmail.com>
	<CABsx9T14Dfh8SEe6wsCJjE=S8hTcfDrAUNMBCjtkvM+UH-bAYQ@mail.gmail.com>
	<CAGRKETunznLbBZO1gnS7WZH5sn=TnmKPS4Gz_Nrtocoe5devbw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGRKETunznLbBZO1gnS7WZH5sn=TnmKPS4Gz_Nrtocoe5devbw@mail.gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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