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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VfSsn-0000rY-T1
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Nov 2013 11:08:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VfSsm-0006nX-Ip
for bitcoin-development@lists.sourceforge.net;
Sun, 10 Nov 2013 11:08:45 +0000
Received: by mail-oa0-f53.google.com with SMTP id j17so4277362oag.12
for <bitcoin-development@lists.sourceforge.net>;
Sun, 10 Nov 2013 03:08:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr13872852obh.27.1384081719160;
Sun, 10 Nov 2013 03:08:39 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Sun, 10 Nov 2013 03:08:38 -0800 (PST)
In-Reply-To: <0887034B-AA65-468B-A8DB-4DF1E6C27DA2@gmail.com>
References: <0887034B-AA65-468B-A8DB-4DF1E6C27DA2@gmail.com>
Date: Sun, 10 Nov 2013 12:08:38 +0100
X-Google-Sender-Auth: fktnxekxMOd4TqGbIi2oDuw7awQ
Message-ID: <CANEZrP0tAb0G700qXhmWJ4ChEfys87KCwUp1CAUQ9sfyHOCxbQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Taylor Gerring <taylor.gerring@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2903c36192b04ead0a3ec
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VfSsm-0006nX-Ip
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Extending the Payment Protocol with vCards
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: Sun, 10 Nov 2013 11:08:46 -0000
--001a11c2903c36192b04ead0a3ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hey Taylor,
It's great to see people thinking about payment protocol extensions. I'm
not totally convinced vCard support is the best idea relative to social
network integration - I can't recall the last time I saw someone use a
vCard. However, that should not hold you back from experimenting or
prototyping. All an extension requires is some tag numbers and we're not in
danger of running out of numbers any time soon.
The reason I favour social network integration is because those are the
ID's people already have. Distributed social networks (like the PGP web of
trust) have never really taken off, and fixing that is an entirely separate
project to Bitcoin.
Doing so is quite easy. Major social networks all have a concept of a user
ID, moreover, one that can be queried without any kind of API authorization
for basic info. Examples:
https://graph.facebook.com/i.am.the.real.mike
https://plus.google.com/s2/u/0/photos/profile/114798402540078632611
So you could simply embed a social network URL into a payment request, and
use that to associate a name/photo with a payment. That would be
unauthenticated (the sender is not proving they are the real owner of the
social network profile). However, authentication may not turn out to be
necessary. If it were to be, then steganographically embedding a key into
the profile picture and signing the payment request with it would be a way
to do so.
On Sat, Nov 9, 2013 at 6:43 PM, Taylor Gerring <taylor.gerring@gmail.com>wr=
ote:
> Hi everyone,
>
> I made a post on the BitcoinTalk forums <
> https://bitcointalk.org/index.php?topic=3D329229.0> outlining how the
> Payment Protocol could be extended with optional vCard support to increas=
e
> the usability of Payment Protocol for user-to-user transactions and impro=
ve
> the user experience in wallets supporting PP.
>
> I=E2=80=99ve outlined the concept in as much detail as my feeble brain ca=
n handle,
> drawing on BIP 0070 itself and Mike Hearn=E2=80=99s Payment Protocol FAQ.=
I know
> there is interest in =E2=80=9Ccontact exchange=E2=80=9D functionality fro=
m the Hive team,
> so I=E2=80=99m hoping this will begin a discussion on how we can make wal=
lets more
> friendly in a standard way.
>
> Please read, digest, and let me know if you have any feedback.
>
> Thanks,
>
> Taylor Gerring
>
>
>
>
>
> -------------------------------------------------------------------------=
-----
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the mo=
st
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11c2903c36192b04ead0a3ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Taylor,<div><br></div><div>It's great to see peopl=
e thinking about payment protocol extensions. I'm not totally convinced=
vCard support is the best idea relative to social network integration - I =
can't recall the last time I saw someone use a vCard. However, that sho=
uld not hold you back from experimenting or prototyping. All an extension r=
equires is some tag numbers and we're not in danger of running out of n=
umbers any time soon.</div>
<div><br></div><div>The reason I favour social network integration is becau=
se those are the ID's people already have. Distributed social networks =
(like the PGP web of trust) have never really taken off, and fixing that is=
an entirely separate project to Bitcoin.</div>
<div><br></div><div>Doing so is quite easy. Major social networks all have =
a concept of a user ID, moreover, one that can be queried without any kind =
of API authorization for basic info. Examples:</div><div><br></div><div>
<a href=3D"https://graph.facebook.com/i.am.the.real.mike">https://graph.fac=
ebook.com/i.am.the.real.mike</a></div><div><a href=3D"https://plus.google.c=
om/s2/u/0/photos/profile/114798402540078632611">https://plus.google.com/s2/=
u/0/photos/profile/114798402540078632611</a><br>
</div><div><br></div><div>So you could simply embed a social network URL in=
to a payment request, and use that to associate a name/photo with a payment=
. That would be unauthenticated (the sender is not proving they are the rea=
l owner of the social network profile). However, authentication may not tur=
n out to be necessary. If it were to be, then steganographically embedding =
a key into the profile picture and signing the payment request with it woul=
d be a way to do so.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
Nov 9, 2013 at 6:43 PM, Taylor Gerring <span dir=3D"ltr"><<a href=3D"ma=
ilto:taylor.gerring@gmail.com" target=3D"_blank">taylor.gerring@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">Hi everyone,<br>
<br>
I made a post on the BitcoinTalk forums <<a href=3D"https://bitcointalk.=
org/index.php?topic=3D329229.0" target=3D"_blank">https://bitcointalk.org/i=
ndex.php?topic=3D329229.0</a>> outlining how the Payment Protocol could =
be extended with optional vCard support to increase the usability of Paymen=
t Protocol for user-to-user transactions and improve the user experience in=
wallets supporting PP.<br>
<br>
I=E2=80=99ve outlined the concept in as much detail as my feeble brain can =
handle, drawing on BIP 0070 itself and Mike Hearn=E2=80=99s Payment Protoco=
l FAQ. I know there is interest in =E2=80=9Ccontact exchange=E2=80=9D funct=
ionality from the Hive team, so I=E2=80=99m hoping this will begin a discus=
sion on how we can make wallets more friendly in a standard way.<br>
<br>
Please read, digest, and let me know if you have any feedback.<br>
<br>
Thanks,<br>
<br>
Taylor Gerring<br>
<br>
<br>
<br>
<br>-----------------------------------------------------------------------=
-------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a11c2903c36192b04ead0a3ec--
|
