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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1RaQ1S-0006h9-Es
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 10:55:46 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=mh.in.england@gmail.com;
helo=mail-ww0-f41.google.com;
Received: from mail-ww0-f41.google.com ([74.125.82.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RaQ1M-0005y3-QL
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 10:55:46 +0000
Received: by wgbdt12 with SMTP id dt12so10362751wgb.4
for <bitcoin-development@lists.sourceforge.net>;
Tue, 13 Dec 2011 02:55:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.92.68 with SMTP id ck4mr11853005wib.27.1323773734674; Tue,
13 Dec 2011 02:55:34 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.216.8.7 with HTTP; Tue, 13 Dec 2011 02:55:34 -0800 (PST)
In-Reply-To: <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
<CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
<201112121841.39864.luke@dashjr.org>
<CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
<CAGQP0AGY32QP=rXyGftb5NbHA7fhcCne7W=pt5+onXp1Jbm98Q@mail.gmail.com>
<1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com>
Date: Tue, 13 Dec 2011 11:55:34 +0100
X-Google-Sender-Auth: bv5Zjqw10ApOthe8WBetlYK2QIk
Message-ID: <CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=f46d043c806c37dfc204b3f7170d
X-Spam-Score: -0.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 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: 1RaQ1M-0005y3-QL
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
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: Tue, 13 Dec 2011 10:55:46 -0000
--f46d043c806c37dfc204b3f7170d
Content-Type: text/plain; charset=UTF-8
>
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the
> wall a picture of their QR code and a bitcoin address. I don't own a mobile
> phone so the QR code is
> useless.
Fixed addresses like that are a temporary thing during Bitcoins maturation
period. They lead to merchants exposing data they probably don't realize
they're exposing, like their income, which is basically unacceptable for
any payment system.
There's no point trying to optimize a case where:
1) You are in the minority (no phone?)
2) The "perfect experience" leaks private data in such a way that would be
deemed a gross security breach by any serious payment processor.
OK, some thoughts on the general proposal, from the POV of what it'd take
for a large deployment, like for every Gmail or every Facebook user. In
terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing
by a large margin. Big sites, even small sites, typically have high-speed
load balancing and demuxing already implemented for HTTP[S] and it's
usually easy to add new endpoints. The same is *not* true of DNS, and
whilst coding up a custom DNS server is possible it's definitely a worse
fit.
FirstBits seems out of the question for the same privacy reasons as given
above. No banking system worth its salt would let everyone look up other
peoples income.
The simplest approach would be to request a full public key with an HTTPS
request like
foo@domain ->
https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob
If you then want to turn the resulting public key into an address before
creating a transaction you can obviously do that.
BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a
big pile of source code. I think it's the same as above, but it's hard to
tell without more effort.
--f46d043c806c37dfc204b3f7170d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was in brmlab a=
nd wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of t=
heir QR code and a bitcoin address. I don't own a mobile phone so the Q=
R code is<br>
useless.</blockquote><div><br></div><div>Fixed addresses like that are a te=
mporary thing during Bitcoins maturation period. They lead to merchants exp=
osing data they probably don't realize they're exposing, like their=
income, which is basically unacceptable for any payment system.</div>
<div><br></div><div>There's no point trying to optimize a case where:</=
div><div><br></div><div>1) You are in the minority (no phone?)</div><div>2)=
The "perfect experience" leaks private data in such a way that w=
ould be deemed a gross security breach by any serious payment processor.</d=
iv>
<div><br></div><div>OK, some thoughts on the general proposal, from the POV=
of what it'd take for a large deployment, like for every Gmail or ever=
y Facebook user. In terms of ease of implementation it is ordered HTTPS/HTT=
P then DNS trailing by a large margin. Big sites, even small sites, typical=
ly have high-speed load balancing and demuxing already implemented for HTTP=
[S] and it's usually easy to add new endpoints. The same is <i>not</i> =
true of DNS, and whilst coding up a custom DNS server is possible it's =
definitely a worse fit.</div>
<div><br></div><div>FirstBits seems out of the question for the same privac=
y reasons as given above. No banking system worth its salt would let everyo=
ne look up other peoples income.</div><div><br></div><div>The simplest appr=
oach would be to request a full public key with an HTTPS request like</div>
<div><br></div><div>=C2=A0 =C2=A0foo@domain -> <a href=3D"https://domain=
/_bitcoin/getnewkey?user=3Dfoo&label=3DPayment%20from%20Bob">https://do=
main/_bitcoin/getnewkey?user=3Dfoo&label=3DPayment%20from%20Bob</a></di=
v><div><br></div>
<div>If you then want to turn the resulting public key into an address befo=
re creating a transaction you can obviously do that.</div><div><br></div><d=
iv>BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is =
a big pile of source code. I think it's the same as above, but it's=
hard to tell without more effort.</div>
</div>
--f46d043c806c37dfc204b3f7170d--
|
