Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.41 as permitted sender)
	client-ip=74.125.82.41; envelope-from=timon.elviejo@gmail.com;
	helo=mail-ww0-f41.google.com; 
MIME-Version: 1.0
In-Reply-To: <1323751122.9491.140661010910705@webmail.messagingengine.com>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<1323751122.9491.140661010910705@webmail.messagingengine.com>
Date: Tue, 13 Dec 2011 08:41:48 +0100
Message-ID: <CAGQP0AFPuoMfJFD_5BZXXwAgN97rwtOrF4xJJFO9=zQyUrcPfA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
To: theymos <theymos@mm.st>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

@Matt
I didn't thought about firstbits scalability, but the "registering
crap" and squatting arguments don't apply to green addresses because
no one wants fancy or easy to memorize names there. Is just a way to
make the bitcoin addresses shorter in the green addresses protocol to
be able to have various of them in the same QR-code.

@Amir
I see, the point is to be able to type the alias directly into the client.

I like the DNS proposal. This would allow for both well known working
centralized technology and namecoin (not proven, but decentralized)
options to be used.


2011/12/13, theymos <theymos@mm.st>:
> I like the user@server.com model. The protocol should be done entirely
> in DNS, though, not using HTTP connections to the server. Then the
> protocol can easily be used with Namecoin or other DNS
> replacements/enhancements later. Crypto to prevent MITM attacks can be
> an optional part of the protocol.
>
> Almost all users will be unable to set up *any* always-on Internet
> service to answer queries, so I'm not too concerned about how easy it is
> to set up the server software.
>
> I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
> forever because private keys can't be transferred safely. All short
> names will be taken quickly. It will also be very expensive for clients
> to query this themselves.
>
> The CA model is broken and it should never be used by Bitcoin.
>
> -------------------------------------------------------------------------=
-----
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


--=20
Jorge Tim=F3n