summaryrefslogtreecommitdiff
path: root/b1/566c171b3634b6542f1c9e4edff464040d6302
blob: c7e6d1b776ba61fe6e556aac44df9b08f790eb5f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
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 <sipa@ulyssis.org>) 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 <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>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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