Date: Fri, 16 Dec 2011 17:17:00 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Rick Wesson <rick@support-intelligence.com>
Message-ID: <20111216161653.GA11672@ulyssis.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<20111216083536.GA20470@ulyssis.org>
	<CAJ1JLtsRGF8wQBE0Uym67baw4wWT6hGamGjSPWyuB_em479y9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJ1JLtsRGF8wQBE0Uym67baw4wWT6hGamGjSPWyuB_em479y9Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote:
> Hardening the protocols and usability are related. Please look at some
> of the work done in the IETF which has a long history in addressing
> many of the issues you are considering. Review some of the elegance in
> the bitcoin protocols. The proposals in this thread are neither clear
> nor elegant. If you can't reach nearly the same level of
> sophistication then I suggest you rethink your scheme.

That's why you use URI + bitcoin address pairs, and use SSL communication
authenticated using the respective bitcoin pubkey. They may spoof your DNS
server, they can't fake having the requested corresponding private key.

Obviously, this moves the problem to getting the URL + address securely
to the client that wants to interact with it, but that is inevitable if
you're not going to rely on a pre-trusted certificate authority and PKI.

Also, the client software can cache the address corresponding to a particular
server or URL, making it similar to an ssh client that caches host keys and
warns when they change.

-- 
Pieter