Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbaTB-0000Ma-KN for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 16:17:13 +0000 X-ACL-Warn: Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] helo=cavuit01.kulnet.kuleuven.be) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RbaT7-0003jk-G0 for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 16:17:13 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 5FFF5138099.A5670 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 5FFF5138099; Fri, 16 Dec 2011 17:17:00 +0100 (CET) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id 33A8531E703; Fri, 16 Dec 2011 17:17:00 +0100 (CET) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id 36AF510052; Fri, 16 Dec 2011 18:17:25 +0100 (CET) Received: by wop.ulyssis.org (Postfix, from userid 615) id 4BC4D87C1AB; Fri, 16 Dec 2011 17:17:00 +0100 (CET) Date: Fri, 16 Dec 2011 17:17:00 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: Rick Wesson Message-ID: <20111216161653.GA11672@ulyssis.org> References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <20111216083536.GA20470@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1RbaT7-0003jk-G0 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] [BIP 15] Aliases X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 16:17:13 -0000 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