Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=andyparkins@gmail.com;
	helo=mail-fx0-f47.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net, Amir Taaki <zgenjix@yahoo.com>
Date: Tue, 13 Dec 2011 16:22:00 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
	<CABsx9T1wksXjLy=EC6dK1WtVFEayL-HgXWtENgSPXhU6Du2Srg@mail.gmail.com>
	<1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
In-Reply-To: <1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2373416.GlT41jfGsN";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112131622.08158.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Precedence: list

--nextPart2373416.GlT41jfGsN
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 2011 December 13 Tuesday, Amir Taaki wrote:

> Maybe I wasn't clear enough in the document, but this is the intent with
> the HTTPS proposal.

I don't like the idea of a hard-coded mapping at all.  We shouldn't be maki=
ng=20
choices on behalf of server operators.  It's up to them how they arrange th=
eir=20
domain names and paths.

I also agree that DNS is not the technology to use.  DNS is a nightmare.

> genjix@foo.org
>=20
> Contacts https://foo.org/bitcoin-alias/?handle=3Dgenjix and the system
> responds with a bitcoin address. Whether the system gives you a new
> address from a pool of addresses, or contacts the merchant behind the
> scenes is implementation defined.
>=20
> I'll clarify it later. This is the relevant line:
>=20
> string strRequestUrl =3D strDomain + "/bitcoin-alias/?handle=3D" +
> pszEncodedNick;
>=20
> Between HTTPS service and server service, I lean slightly towards HTTPS
> (automatic encrypted connection, CAs + all benefits of DNS). But still
> interested in arguments in favour of a server service (daemon answering
> queries).

Why bother with an encoding scheme at all?  If the address

  genjix@foo.org

always maps to

  https://foo.org/bitcoin-alias/?handle=3Dgenjix

Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and=
=20
"?handle=3D" and the original email-looking "genjix@foo.org".  Just use the=
 URL. =20
Then the author of the service can use whatever they want.

 "Can I pay you 10 BTC?"
 "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"

While I might implement my alias server like this:

 "Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
 "Sure, send it to 'https://parkins.co.uk/"

=2E.. or any other URL they want -- any of which suit might suit me and my=
=20
webserver better than whatever mapping would otherwise be hard-coded.  The=
=20
world is already very familiar with URLs so this is no more scary than the=
=20
email address.  What's more, the email address form looks _too much_ like a=
n=20
email address, and will only lead to confusion ... "send it to genjix@foo.o=
rg" =20
"so I use outlook express for that, right?"  "erm, no, you put it in your=20
bitcoin client".

The URL form could easily be made to detect a browser connecting rather tha=
n a=20
bitcoin client (and this is an area that would benefit from a standards=20
document -- define the headers and user agent triggers that an alias server=
=20
expects) and give them better instructions.

https can be specified as the default, so  "https://" can be optional when=
=20
they're typing.  If, in the future, bitcoin gets a distributed peer-to-peer=
=20
alias system, then a new URL type can be added easily "bcalias://andyparkin=
s"=20
might automatically find my node in the network and query it for an address=
=20
(or whatever).

All of the above is exactly why OpenID chose to use URLs for ID.


Andy

=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart2373416.GlT41jfGsN
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk7ne6kACgkQwQJ9gE9xL22tDACfaix7dRiXPos9D0AlMjWFudpc
p0UAnRa7zpQHWCuwQnX8vH4uwQnNHq9l
=Lz35
-----END PGP SIGNATURE-----

--nextPart2373416.GlT41jfGsN--