summaryrefslogtreecommitdiff
path: root/40/3bb4d0054ecaf2f6e34d5bb06b1bf966cffc02
blob: 59faebb2bb84f7607ddbde71f9edc1b947940aa8 (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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <k@old.school.nz>) id 1RbNfa-0003fC-9l
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 02:37:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of old.school.nz
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=k@old.school.nz;
	helo=mail-vw0-f47.google.com; 
Received: from mail-vw0-f47.google.com ([209.85.212.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RbNfZ-0008N2-EC
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Dec 2011 02:37:10 +0000
Received: by vbbfc21 with SMTP id fc21so2989227vbb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 15 Dec 2011 18:37:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.93.240 with SMTP id cx16mr4771918vdb.99.1324003023744; Thu,
	15 Dec 2011 18:37:03 -0800 (PST)
Received: by 10.220.107.70 with HTTP; Thu, 15 Dec 2011 18:37:03 -0800 (PST)
X-Originating-IP: [219.89.81.27]
In-Reply-To: <1323979147.27319.140661012141129@webmail.messagingengine.com>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<1323979147.27319.140661012141129@webmail.messagingengine.com>
Date: Fri, 16 Dec 2011 15:37:03 +1300
Message-ID: <CA+QPp0qGohZO2o-a0D1kxOE==w8keX=uvO_PDcDRHbP=sTTN5w@mail.gmail.com>
From: Kyle Henderson <k@old.school.nz>
To: theymos <theymos@mm.st>
Content-Type: multipart/alternative; boundary=20cf3071caa4e96eb704b42c7909
X-Spam-Score: -0.5 (/)
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
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1RbNfZ-0008N2-EC
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 02:37:10 -0000

--20cf3071caa4e96eb704b42c7909
Content-Type: text/plain; charset=UTF-8

This is the first proposal I've seen regarding mapping something like
user@host that actually makes sense to me.

Bitcoin itself is decentralised by design, in my opinion it seems obvious
that it needs to continue to maintain this feature.


On Fri, Dec 16, 2011 at 8:59 AM, theymos <theymos@mm.st> wrote:

> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>  public key
> - Extend "checkorder" messages so they can specify an account to
>  send BTC to. Or standardize on how to put the account into the
>  message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>  also be used here to avoid having to use the IP transaction protocol
>  sometimes. The public key for signing "reply" messages can be gotten
>  from TXT records. This will be safe with DNSSEC and Namecoin. With
>  plain DNS Bitcoin could take a SSH-like approach and ask the user to
>  verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
>

--20cf3071caa4e96eb704b42c7909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">This is the first proposal I&#39;ve seen regardi=
ng mapping something like user@host that actually makes sense to me.<br>
			<br>
			Bitcoin itself is decentralised by design, in my opinion it seems obviou=
s that it needs to continue to maintain this feature.<br><br><br>On Fri, De=
c 16, 2011 at 8:59 AM, theymos <span dir=3D"ltr">&lt;<a href=3D"mailto:they=
mos@mm.st">theymos@mm.st</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Bitcoin already has code and a protocol for =
transactions to IP<br>
addresses. Why not reuse that for dynamic address lookup? Just a few<br>
changes are necessary to enable complete <a href=3D"mailto:user@server.com"=
>user@server.com</a> handling:<br>
- Extend the protocol so that &quot;reply&quot; messages can be signed by a=
 fixed<br>
 =C2=A0public key<br>
- Extend &quot;checkorder&quot; messages so they can specify an account to<=
br>
 =C2=A0send BTC to. Or standardize on how to put the account into the<br>
 =C2=A0message field.<br>
- Enable DNS lookups for IP transactions. The DNS-only proposals could<br>
 =C2=A0also be used here to avoid having to use the IP transaction protocol=
<br>
 =C2=A0sometimes. The public key for signing &quot;reply&quot; messages can=
 be gotten<br>
 =C2=A0from TXT records. This will be safe with DNSSEC and Namecoin. With<b=
r>
 =C2=A0plain DNS Bitcoin could take a SSH-like approach and ask the user to=
<br>
 =C2=A0verify the public key the first time it is used, remembering it late=
r.<br>
<br>
DoS attacks are already handled by the IP transactions code: the same IP<br=
>
address is always given the same bitcoin address until it pays to that<br>
bitcoin address.<br>
<div class=3D"im HOEnZb"><br></div></blockquote></div>

--20cf3071caa4e96eb704b42c7909--