summaryrefslogtreecommitdiff
path: root/3e/366030056ee205b747b581a8e50227cab6c71f
blob: 86c33e9c61e622e8686dac4a3d7541375a5f4527 (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bitcoin-list@bluematt.me>) id 1RaFuf-00050X-Sp
	for bitcoin-development@lists.sourceforge.net;
	Tue, 13 Dec 2011 00:08:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1RaFuf-0008Pt-0y for bitcoin-development@lists.sourceforge.net;
	Tue, 13 Dec 2011 00:08:05 +0000
Received: from [152.23.99.207] (dhcp05033.highsouth-resnet.unc.edu
	[152.23.99.207])
	by mail.bluematt.me (Postfix) with ESMTPSA id 181AF3E0
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 13 Dec 2011 00:47:30 +0100 (CET)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
	<CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 12 Dec 2011 18:52:45 -0500
Message-ID: <1323733965.3353.15.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -3.8 (---)
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 SPF_PASS               SPF: sender matches SPF record
	-2.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1RaFuf-0008Pt-0y
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: Tue, 13 Dec 2011 00:08:06 -0000

On Tue, 2011-12-13 at 00:37 +0100, Jorge Tim=C3=B3n wrote:
> 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.
Firstbits isn't acceptable for anything.  As Amir originally pointed
out, it doesn't scale well and worst of all it fills the blockchain with
a ton of crap to get 1 satoshi at an address so that it is
"registered". =20
>=20
> 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.
Firstbits is unacceptable because it causes unnecessary harm to each
Bitcoin node.  However, if one were to use a chain specifically crafted
for such a purpose isn't terrible.  That said, it still doesn't scale
well and if it becomes popular virtually every implementation would have
to rely on trusted servers at which point you are better off going back
to an HTTPS/DNSSEC-based implementation

Matt