From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Kyle Henderson To: theymos 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
This is the first proposal I've seen regardi= ng mapping something like user@host that actually makes sense to me.

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


On Fri, De= c 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
=C2=A0public key
- Extend "checkorder" messages so they can specify an account to<= br> =C2=A0send BTC to. Or standardize on how to put the account into the
=C2=A0message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
=C2=A0also be used here to avoid having to use the IP transaction protocol=
=C2=A0sometimes. The public key for signing "reply" messages can= be gotten
=C2=A0from TXT records. This will be safe with DNSSEC and Namecoin. With =C2=A0plain DNS Bitcoin could take a SSH-like approach and ask the user to=
=C2=A0verify the public key the first time it is used, remembering it late= r.

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--