Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
	helo=mail-ww0-f53.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 15 Dec 2011 10:01:14 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <CA+QPp0rAJz9wPcrf926q=_c45mCL_67JCyacvM79CWcic9AL2w@mail.gmail.com>
	<CAGQP0AFD9q+=vZPod_n_LJjCjzVnVy5w3hq4N07JZRM6=Ly-FQ@mail.gmail.com>
	<CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@mail.gmail.com>
In-Reply-To: <CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart24076967.RVlZ8CDTU3";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112151001.23274.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Precedence: list

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

On 2011 December 15 Thursday, Walter Stanish wrote:

> > Andy sounded very convincing when talking in favor of URLs. What's
> > wrong with his proposal?
>=20
> A URI identifies a resource and is in effect an alias itself.
> Identifying a resource is different from interacting with it. So,
> while <resource-type>://<resource-type-specific-alias> will work
> sufficiently for the identification, it does not explain the
> interaction.

Quite so; the BIP15 standard shouldn't be setting the format of the URI; it=
=20
should be setting what the format of the client-server conversation is. =20
Effectively, what headers will a requesting client send?  What headers shou=
ld=20
a server require?  What will a server respond?

> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.

I think that's missing the point; any aliasing scheme is definitely reducin=
g=20
your anonymity, neccessarily so -- the alias has to be looked up somewhere,=
=20
that somewhere reduces anonymity.  If anonymity is what you want, stick wit=
h=20
just a bitcoin address.  The point of an aliasing server is surely to be ab=
le=20
to give a single, unchanging, well known label to a transacting party, but=
=20
still enable that party to generate a new address per transaction.

I want my webshop to be able to say "please pay 3.20 BTC to=20
https://mywebshop.com/payments/orderid=3D27282" to enable the automatic=20
connection from orderid to bitcoin address (which my payment system can the=
n=20
monitor for payment receipt).  (This is just one example).

> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Well yes; but then the client has no idea what address to send to unless it=
=20
connects to that URI... interaction/address generation is done when that=20
connection is made.

In short: I don't really think that this aliasing system should be concerni=
ng=20
itself with preserving anonymity of the receiving party.  That is almost=20
certainly already gone (I'm hardly likely to send money to someone I don't=
=20
know unless I like gifting random cash).  The sending party loses a little=
=20
anonymity because their IP is revealed when they connect to the aliasing=20
system.  But there is very little anonymity in a supplier-client relationsh=
ip=20
anyway (you have to say what goods you want, and where you want them, and y=
ou=20
had to interact with a website when you were ordering already).



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

--nextPart24076967.RVlZ8CDTU3
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)

iEYEABECAAYFAk7pxWsACgkQwQJ9gE9xL22zfwCfSLPpzbxOAHlIrQuwBJEmPw8X
2VEAmwUzL8kgNMScvGnk69dmyce5bg7F
=jKoN
-----END PGP SIGNATURE-----

--nextPart24076967.RVlZ8CDTU3--