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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
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 <timon.elviejo@gmail.com>) id 1RaFRd-0000PC-8R
for bitcoin-development@lists.sourceforge.net;
Mon, 12 Dec 2011 23:38:05 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=timon.elviejo@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1RaFRc-0002qN-CL
for bitcoin-development@lists.sourceforge.net;
Mon, 12 Dec 2011 23:38:05 +0000
Received: by wgbds1 with SMTP id ds1so11479042wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 Dec 2011 15:37:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.189.147 with SMTP id c19mr2952096wen.92.1323733076260;
Mon, 12 Dec 2011 15:37:56 -0800 (PST)
Received: by 10.223.81.79 with HTTP; Mon, 12 Dec 2011 15:37:56 -0800 (PST)
In-Reply-To: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
Date: Tue, 13 Dec 2011 00:37:56 +0100
Message-ID: <CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
To: Zell Faze <zellfaze@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timon.elviejo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RaFRc-0002qN-CL
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: Mon, 12 Dec 2011 23:38:05 -0000
I don't think Amir wants to put it into the protocol, but I still
don't like much the proposal if it has to rely on servers.
As an aside, even if firstbits it's not useful enough for the human
memory, it is still useful for QR-codes like in the case of green
addresses's POS instant payments.
Would it be too strange to use namecoin?
Some devices may need to rely on block exploring servers, but it is
the easiest decentralized solution that comes to mind.
2011/12/13, Zell Faze <zellfaze@yahoo.com>:
> I agree with Luke-Jr. We need to try to find a decentralized solution if=
we
> are going to implement BIP 15. Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the HTTPS idea would be a great idea for a client feature, bu=
t
> not really something that should be added to the protocol.
>
> --- On Mon, 12/12/11, Luke-Jr <luke@dashjr.org> wrote:
>
>> From: Luke-Jr <luke@dashjr.org>
>> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
>> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki"
>> <zgenjix@yahoo.com>
>> Date: Monday, December 12, 2011, 5:32 PM
>> FirstBits looks nice at glance, but
>> is bound to create a gold-rush to grab
>> every nice-looking FirstBits address.
>>
>> HTTPS is only as secure as the (centralized) CAs, thus not
>> really any better
>> than TXT records.
>>
>> I don't think an address of some form is avoidable.
>
>
> -------------------------------------------------------------------------=
-----
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what i=
t
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--=20
Jorge Tim=F3n
|
