Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]