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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ewillbefull@gmail.com>) id 1V4gCF-0007zB-AS
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 23:52:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.172 as permitted sender)
client-ip=74.125.82.172; envelope-from=ewillbefull@gmail.com;
helo=mail-we0-f172.google.com;
Received: from mail-we0-f172.google.com ([74.125.82.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V4gCE-0003lp-JW
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 23:52:47 +0000
Received: by mail-we0-f172.google.com with SMTP id t61so1149303wes.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 31 Jul 2013 16:52:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.22.227 with SMTP id h3mr260115wjf.7.1375314760413; Wed,
31 Jul 2013 16:52:40 -0700 (PDT)
Received: by 10.194.162.34 with HTTP; Wed, 31 Jul 2013 16:52:40 -0700 (PDT)
In-Reply-To: <CABsx9T22RQrQAAjGQ+hJix3LDXCdGkfMkxvv7xmxy1n4jM7SOw@mail.gmail.com>
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>
<CABsx9T22RQrQAAjGQ+hJix3LDXCdGkfMkxvv7xmxy1n4jM7SOw@mail.gmail.com>
Date: Wed, 31 Jul 2013 17:52:40 -0600
Message-ID: <CAGRKETuDX9ijUaJuo+U17qBwQZwCb4q4g7sJOQE8V9zJmm=B=Q@mail.gmail.com>
From: E willbefull <ewillbefull@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>,
bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b5d8815bfba5d04e2d76b5e
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
(ewillbefull[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: 1V4gCE-0003lp-JW
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, 31 Jul 2013 23:52:47 -0000
--047d7b5d8815bfba5d04e2d76b5e
Content-Type: text/plain; charset=ISO-8859-1
P2SH addresses support exotic transaction outputs, but not all exotic
transactions. This payment protocol can allow for combining multiple
outputs. A PaymentRequest for sending money to multiple parties, for
example, could not fall back to a single address.
On Wed, Jul 31, 2013 at 5:38 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> On Thu, Aug 1, 2013 at 9:30 AM, E willbefull <ewillbefull@gmail.com>
> 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.
>
> P2SH addresses already support all exotic transactions.
>
> > Or, a page with a bitcoin URI link may be
> > relying on a separate service provider to assemble the transaction.
>
> Do you mean assemble the PaymentRequest message? Because the payment
> transaction will always be created by the customer's wallet software.
>
> IF PaymentRequests take over the world and we get 100% wallet software
> support, then I'd be happy to write another BIP that says that a
> bitcoin: URI can be just bitcoin:?request=http...
>
> --
> --
> Gavin Andresen
>
--047d7b5d8815bfba5d04e2d76b5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>P2SH addresses support exotic transaction outputs, bu=
t not all exotic transactions. This payment protocol can allow for combinin=
g multiple outputs. A PaymentRequest for sending money to multiple parties,=
for example, could not fall back to a single address.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
Jul 31, 2013 at 5:38 PM, Gavin Andresen <span dir=3D"ltr"><<a href=3D"m=
ailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Aug 1, 2013 at 9:3=
0 AM, E willbefull <<a href=3D"mailto:ewillbefull@gmail.com">ewillbefull=
@gmail.com</a>> wrote:<br>
> I think it's important to expect PaymentRequest-only bitcoin URIs =
in the<br>
> future. Some types of payments (exotic transactions) may not make sens=
e to<br>
> have a single fallback address.<br>
<br>
</div>P2SH addresses already support all exotic transactions.<br>
<div class=3D"im"><br>
> Or, a page with a bitcoin URI link may be<br>
> relying on a separate service provider to assemble the transaction.<br=
>
<br>
</div>Do you mean assemble the PaymentRequest message? =A0Because the payme=
nt<br>
transaction will always be created by the customer's wallet software.<b=
r>
<br>
IF PaymentRequests take over the world and we get 100% wallet software<br>
support, then I'd be happy to write another BIP that says that a<br>
bitcoin: URI can be just bitcoin:?request=3Dhttp...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
--<br>
Gavin Andresen<br>
</font></span></blockquote></div><br></div>
--047d7b5d8815bfba5d04e2d76b5e--
|
