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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Precedence: list

--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&#39;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&#39;t realize they&#39;re exposing, like their=
 income, which is basically unacceptable for any payment system.</div>
<div><br></div><div>There&#39;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 &quot;perfect experience&quot; 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&#39;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&#39;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&#39;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 -&gt; <a href=3D"https://domain=
/_bitcoin/getnewkey?user=3Dfoo&amp;label=3DPayment%20from%20Bob">https://do=
main/_bitcoin/getnewkey?user=3Dfoo&amp;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&#39;s the same as above, but it&#39;s=
 hard to tell without more effort.</div>
</div>

--f46d043c806c37dfc204b3f7170d--