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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D0BBBCB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Mar 2016 23:07:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com
[209.85.218.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56F29106
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Mar 2016 23:07:13 +0000 (UTC)
Received: by mail-oi0-f51.google.com with SMTP id c203so22578494oia.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Mar 2016 15:07:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=3sDMq/ag03KTzIHf6AIzRL1hNa5VZAzMDyZbfudJ6Kc=;
b=nUNrEzZfBAGq8eV5tUGFd5NOmoVluCaJcufzXQ45KupOea7PIVkDks4RuD0z/wx+7H
wKapO31xcwyicFCafMdnTbLrOT95F7rjvwnJOdSTkJiz5XaVhqRmgfHEPLfSOQXCHcOK
JkmWG9eawAE9fMa/cgb5M8zPgfWsf+h6rCdKczXeXE2e2JDIbXs3UsNpqU1QEyYAqrDb
AYZaCw0iPWv8Yfk9e1TiG5rcwyx1oiMe4ZVGGNlJW3QCVGyzwERqoGVyJsH9eecCndZa
uzTHPbZrn4VBxf8IA7TSOptBlNSVQLhDeDYzxSLfrrBafiw/8UnmhOSzc5W/SO1wP0Lv
QZ+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=3sDMq/ag03KTzIHf6AIzRL1hNa5VZAzMDyZbfudJ6Kc=;
b=cRqDC7CYPweRn6LfoSEgOrtPn+h82aRPH6l5iSxkK4zQggXaxZl6od70sV02CQhVRh
Q+s6Bu9+ejKn7Z3IEAbF3nMFQeiW8L7IiuEcrMtkmVgjnqpZrecqMy5+5Kl7OXBIkFLy
KCDeHM1L+sn5Ws2eIJjWOSn/t6l1INpkeRBsDvW3dnx1PBZK/2Nm0BOEFcMSTP6ppayo
eqePKbj7dwZMFRW7vk/b8QiDEn45QiL/J1O88vjmnx5galJqL9jmmCNvx1Nl+nmpC/Gq
u9zqUYC+rz7pctltcr+MWhHZ+MKsNm8mb6s4SlOglukbO8sM4WDWY5W8apC50hNh6jq7
6D0g==
X-Gm-Message-State: AD7BkJJqBNeVbk1KflauvMFNuil4DPLF28/ZlKioVwHlk1u3u96OJ//AsGRh0eUbYnMbP6YRjbguVvy36GbUmg==
X-Received: by 10.202.193.10 with SMTP id r10mr19538801oif.126.1457478432705;
Tue, 08 Mar 2016 15:07:12 -0800 (PST)
MIME-Version: 1.0
References: <CABqynx+gGnJ2AVByr1eKueSaohHtJVFsAVKrfS94StW2NzLWjw@mail.gmail.com>
<201603082234.14398.luke@dashjr.org>
In-Reply-To: <201603082234.14398.luke@dashjr.org>
From: James MacWhyte <macwhyte@gmail.com>
Date: Tue, 08 Mar 2016 23:07:03 +0000
Message-ID: <CAH+Axy77qm0Ls3vNFxhbqfaG=PvraX92RqFPKZs7je=qNuSA6Q@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113dc36e3fd361052d91a4e1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 09 Mar 2016 00:00:23 +0000
Subject: Re: [bitcoin-dev] Proposed BIP extension to BIP 0070
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 23:07:14 -0000
X-List-Received-Date: Tue, 08 Mar 2016 23:07:14 -0000
--001a113dc36e3fd361052d91a4e1
Content-Type: text/plain; charset=UTF-8
Our BIP just defines protocol definitions, and doesn't really dictate how
people use them (we're coming up with a new title for the BIP, by the way,
to more accurately convey that). Using our definitions as building blocks,
someone could definitely accomplish what you described. For example, Joe
Mobile Wallet User's wallet could upload a slew of generic PaymentRequest
messages with signatures to prove his identity, and the server could then
create encryptedPaymentRequest messages using the server's key for
encryption and communication with the other party. In this case the server
would essentially be a proxy for the user without having actual access to
the user's private keys.
My personal goal with the protocol was to keep it extremely flexible so
developers could use it to build all different types of schemes while
keeping standard messages that could be forwarded between services if
needed. Does the above make sense?
James
On Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is there a way for Joe Mobile Wallet User to upload a set of N
> PaymentRequests
> authenticated by his key to an untrusted server, which encrypts and passes
> them on in response to InvoiceRequests? Or does this necessarily require
> the
> recipient to be online?
>
> On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
> > The following draft BIP proposes an update to the Payment Protocol.
> >
> > Motivation:
> >
> > The motivation for defining this extension to the BIP70 Payment Protocol
> is
> > to allow 2 parties to exchange payment information in a permissioned and
> > encrypted way such that wallet address communication can become a more
> > automated process. Additionally, this extension allows for the requestor
> of
> > a PaymentRequest to supply a certificate and signature in order to
> > facilitate identification for address release. This also allows
> > for automated creation of off blockchain transaction logs that are human
> > readable, containing who you transacted with, in addition to the
> > information that it contains today.
> >
> > The motivation for this extension to BIP70 is threefold:
> >
> > 1. Ensure that the payment details can only be seen by the participants
> in
> > the transaction, and not by any third party.
> > 2. Enhance the Payment Protocol to allow for store and forward servers in
> > order to allow, for example, mobile wallets to sign and serve
> > Payment Requests.
> > 3. Allow a sender of funds the option of sharing their identity with the
> > receiver. This information could then be used to:
> >
> > * Make bitcoin logs more human readable
> > * Give the user the ability to decide who to release payment
> > details to
> > * Allow an entity such as a political campaign to ensure donors
> > match regulatory and legal requirements
> > * Allow for an open standards based way for regulated financial
> > entities to meet regulatory requirements
> > * Automate the active exchange of payment addresses, so static
> > addresses and BIP32 X-Pubs can be avoided to maintain privacy
> > and convenience
> >
> > In short we wanted to make bitcoin more human, while at the same time
> > improving transaction privacy.
> >
> > Full proposal here:
> >
> >
> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
> > .mediawiki
> >
> > We look forward to your thoughts and feedback on this proposal!
> >
> > Justin
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113dc36e3fd361052d91a4e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:13px;line-height:19.5px">Our BIP =
just defines protocol definitions, and doesn't really dictate how peopl=
e use them (we're coming up with a new title for the BIP, by the way, t=
o more accurately convey that). Using our definitions as building blocks, s=
omeone could definitely accomplish what you described. For example, Joe Mob=
ile Wallet User's wallet could upload a slew of generic PaymentRequest =
messages with signatures to prove his identity, and the server could then c=
reate encryptedPaymentRequest messages using the server's key for encry=
ption and communication with the other party. In this case the server would=
essentially be a proxy for the user without having actual access to the us=
er's private keys.</span><br style=3D"font-size:13px;line-height:19.5px=
"><br style=3D"font-size:13px;line-height:19.5px"><span style=3D"font-size:=
13px;line-height:19.5px">My personal goal with the protocol was to keep it =
extremely flexible so developers could use it to build all different types =
of schemes while keeping standard messages that could be forwarded between =
services if needed. Does the above make sense?</span><div><span style=3D"li=
ne-height:19.5px"><br></span></div><div><span style=3D"line-height:19.5px">=
James<br></span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar=
8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there a way for Joe =
Mobile Wallet User to upload a set of N PaymentRequests<br>
authenticated by his key to an untrusted server, which encrypts and passes<=
br>
them on in response to InvoiceRequests? Or does this necessarily require th=
e<br>
recipient to be online?<br>
<br>
On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:<=
br>
> The following draft BIP proposes an update to the Payment Protocol.<br=
>
><br>
> Motivation:<br>
><br>
> The motivation for defining this extension to the BIP70 Payment Protoc=
ol is<br>
> to allow 2 parties to exchange payment information in a permissioned a=
nd<br>
> encrypted way such that wallet address communication can become a more=
<br>
> automated process. Additionally, this extension allows for the request=
or of<br>
> a PaymentRequest to supply a certificate and signature in order to<br>
> facilitate identification for address release. This also allows<br>
> for automated creation of off blockchain transaction logs that are hum=
an<br>
> readable, containing who you transacted with, in addition to the<br>
> information that it contains today.<br>
><br>
> The motivation for this extension to BIP70 is threefold:<br>
><br>
> 1. Ensure that the payment details can only be seen by the participant=
s in<br>
> the transaction, and not by any third party.<br>
> 2. Enhance the Payment Protocol to allow for store and forward servers=
in<br>
> order to allow, for example, mobile wallets to sign and serve<br>
> Payment Requests.<br>
> 3. Allow a sender of funds the option of sharing their identity with t=
he<br>
> receiver. This information could then be used to:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Make bitcoin logs more human readab=
le<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Give the user the ability to decide=
who to release payment<br>
> details to<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow an entity such as a political=
campaign to ensure donors<br>
> match regulatory and legal requirements<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow for an open standards based w=
ay for regulated financial<br>
> entities to meet regulatory requirements<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Automate the active exchange of pay=
ment addresses, so static<br>
> addresses and BIP32 X-Pubs can be avoided to maintain privacy<br>
> and convenience<br>
><br>
> In short we wanted to make bitcoin more human, while at the same time<=
br>
> improving transaction privacy.<br>
><br>
> Full proposal here:<br>
><br>
> <a href=3D"https://github.com/techguy613/bips/blob/master/bip-invoicer=
equest-extension" rel=3D"noreferrer" target=3D"_blank">https://github.com/t=
echguy613/bips/blob/master/bip-invoicerequest-extension</a><br>
> .mediawiki<br>
><br>
> We look forward to your thoughts and feedback on this proposal!<br>
><br>
> Justin<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
--001a113dc36e3fd361052d91a4e1--
|