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
|
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 <rick.wesson@iidf.org>) id 1RbaG4-0008JM-5x
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 16:03:40 +0000
X-ACL-Warn:
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RbaFy-00030n-J2
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 16:03:40 +0000
Received: by vcbf1 with SMTP id f1so2155161vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 08:03:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.210.196 with SMTP id gl4mr3782085vcb.3.1324051408475; Fri,
16 Dec 2011 08:03:28 -0800 (PST)
Received: by 10.52.37.80 with HTTP; Fri, 16 Dec 2011 08:03:28 -0800 (PST)
In-Reply-To: <20111216083536.GA20470@ulyssis.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<20111216083536.GA20470@ulyssis.org>
Date: Fri, 16 Dec 2011 08:03:28 -0800
Message-ID: <CAJ1JLtsRGF8wQBE0Uym67baw4wWT6hGamGjSPWyuB_em479y9Q@mail.gmail.com>
From: Rick Wesson <rick@support-intelligence.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RbaFy-00030n-J2
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:03:40 -0000
On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:
>> I wrote this pre-draft:
[snip]
>
> To conclude: my suggestion would be to use URLs as address identifiers,
> optionally suffixed with a bitcoin address for authentication.
> This means my "address" would be either "sipa.be/pw.btc" or
> "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
> is an implicit default. Initiating a payment to either of these would
> result in a GET of https://sipa.be/pw.btc. When a transaction is
> constructed, it is POSTed back to that URL.
>
> If we can agree on reasonable hardcoded mapping, pw@sipa.be could just
> be a shorthand for either of these (though vulnerable to proofing...).
I believe that any URI scheme will still leverage DNS and inherit any
base issues you would have with TXT records. I suggest looking at DANE
and reviewing their work on hardening certificate (x.509)
infrastructure as your HTTPS scheme will inherit the issues we
currently experience with CAs getting p0wned.
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.
-rick
|
