From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rbbm2-0002UG-6E for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 17:40:46 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of dot-bit.org designates 178.32.102.200 as permitted sender) client-ip=178.32.102.200; envelope-from=khal@dot-bit.org; helo=srv01.web-sweet-web.net; Received: from srv01.web-sweet-web.net ([178.32.102.200]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Rbblz-00066Q-IY for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 17:40:45 +0000 Received: by srv01.web-sweet-web.net (Postfix, from userid 1000) id D3E81165E007; Fri, 16 Dec 2011 18:23:48 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on srv01.web-sweet-web.net X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, AWL, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from [10.0.0.2] (sal69-2-82-241-217-146.fbx.proxad.net [82.241.217.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by srv01.web-sweet-web.net (Postfix) with ESMTPSA id C14F1165E005 for ; Fri, 16 Dec 2011 18:23:36 +0100 (CET) Message-ID: <4EEB7E98.8030006@dot-bit.org> Date: Fri, 16 Dec 2011 18:23:36 +0100 From: Khalahan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <1323979147.27319.140661012141129@webmail.messagingengine.com> In-Reply-To: <1323979147.27319.140661012141129@webmail.messagingengine.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/alternative; boundary="------------060608040301030600010103" X-Spam-Score: -1.0 (-) 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 -0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Rbblz-00066Q-IY 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 17:40:46 -0000 This is a multi-part message in MIME format. --------------060608040301030600010103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Namecoin is a peer-to-peer generic name/value datastore system. Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin. Namecoin is *specificaly designed to map things to names* in a fully decentralized way. So, it's the perfect starting point to map names to other things (a public bitcoin address, an url, etc) You won't have all the advantages of namecoin when using other systems like DNS and HTTP(S) as the first entry point. What is namecoin ? * proven technology : - do not mix the namecoin technology and the dot-bit namespace with .bit domains (dot-bit domains needs dot-bit compatible dns servers or proxies + namecoin and have a small visibility due to the nature of top-to-bottom domain name system controlled by ICANN, namecoin needs only namecoin to store data !) - as proven and secure as bitcoin - merged mining provides a secure network * decentralized : - a lot of nodes, and you can have your own node - everybody can register his own name, by itself with the namecoin software (bitcoin could even allow registration directly from it, easily) or by using a name provider - everybody can become a name provider (register for your friends and resell names). * no single point of failure : - DNS and HTTPS have several limitations (Man in the Middle attacks, no reliable authority of certifications, domain seizure, ...) * designed for that : - namecoin uses a system of namespaces to separate each usages : http://dot-bit.org/Main_Page#Namespaces. For example, the "personal namespace" draft (http://dot-bit.org/Personal_Namespace) could be extended to support mapping to a bitcoin address, or a dedicated namespace can be used if prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example). * easily connectable to bitcoin - they both use RPC and json to exchange informations, so connecting one to the other is really easy - bitcoin could even allow registration of names by sending an RPC request to namecoin * extensible and not limited : - you are not forced to store a bitcoin address directly in namecoin, you can also store an url or a domain name - allows additional security : add a certificate fingerprint combined with an https url (so, using DNS or HTTP(S) is not a major problem anymore if the first point of entry is really secure and configurable [and you use and self-signed certificate]) - really easy to update - simple for simple cases - possibility to use a nick, an email address or a domain as name - other methods to get bitcoins addresses can be added later, protocol is extensible Examples of possible registered names in namecoin with the "personal namespace" (with the "p/" prefix) : * An individual person with well known public addresses : "p/*khal*": { "email": "khal@dot-bit.org", "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9" } * Another individual person with well known public addresses : "p/*khal@dot-bit.org*": { "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9" } * A merchant accepting payments in bitcoin, namecoin, paypal or othercoin (to show you how the whole namespace could be used) : "p/*mymerchant.com*": { "bitcoin": { "url": "https://payto.mymerchant.com/bitcoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926" "cert": "https://payto.mymerchant.com/certificate.pem", }, "namecoin": { "url": "https://payto.mymerchant.com/namecoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926" }, "paypal": "xxxxxx@yyyyyyyyy.zzz", "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } * A merchant with a public address, an url to generate custom addresses and a domain name (not sure if this case is really usefull, maybe as fallback) "p/*mymerchant2*": { "bitcoin": { "url": "https://payto.mymerchant.com/bitcoin/", "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926", "dns": "_bitcoin.payto.mymerchant.com", "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", } } * How to use it in bitcoin ? Several possibilities of address syntax : - khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit - mymerchant2@bitcoin : will conflict with names already containing a @ - mymerchant2@namecoin : same - namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme" - namecoin://mymerchant2 : same - other ? Here is how things would be processed when people put an address to pay to in the bitcoin client : * address : khal -> RPC to namecoin for "p/khal" -> json processing for "p/khal->bitcoin" -> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T * address : khal@dot-bit.org -> RPC to namecoin for "p/khal@dot-bit.org" -> json processing for "p/khal@dot-bit.org->bitcoin" -> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T * address : mymerchant.com -> RPC to namecoin for "p/mymerchant.com" -> json processing for "p/mymerchant.com->bitcoin" -> json processing for "p/mymerchant.com->bitcoin->url" and "p/mymerchant.com->bitcoin->fpr" -> https request to "https://payto.mymerchant.com/bitcoin/" -> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy * address : mymerchant2 -> RPC to namecoin for "p/mymerchant2" -> json processing for "p/mymerchant2->bitcoin" -> json processing for "p/mymerchant2->bitcoin->url" and "p/mymerchant2->bitcoin->fpr" -> https request to "https://payto.mymerchant.com/bitcoin/" -> result : error (website unavailable, page not found, timeout, etc) -> json processing for "p/mymerchant2->bitcoin->dns" -> dns request for "_bitcoin.payto.mymerchant.com" -> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy Le 15/12/2011 20:59, theymos a =E9crit : > 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 I= P > address is always given the same bitcoin address until it pays to that > bitcoin address. > > -----------------------------------------------------------------------= ------- > 10 Tips for Better Server Consolidation > Server virtualization is being driven by many needs. =20 > But none more important than the need to reduce IT complexity=20 > while improving strategic productivity. Learn More!=20 > http://www.accelacomm.com/jaw/sdnl/114/51507609/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --=20 Best Regards, Khalahan http://dot-bit.org/ --------------060608040301030600010103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Namecoin is a peer-to-peer generic name/value datastore system.
Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin.

Namecoin is specificaly designed to map things to names in a fully decentralized way. So, it's the perfect starting point to map names to other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems like DNS and HTTP(S) as the first entry point.

What is namecoin ?

* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit domains (dot-bit domains needs dot-bit compatible dns servers or proxies + namecoin and have a small visibility due to the nature of top-to-bottom domain name system controlled by ICANN, namecoin needs only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network

* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin software (bitcoin could even allow registration directly from it, easily) or by using a name provider
- everybody can become a name provider (register for your friends and resell names).

* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no reliable authority of certifications, domain seizure, ...)

* designed for that :
- namecoin uses a system of namespaces to separate each usages : http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft (http://dot-bit.org/Personal_Namespace) could be extended to support mapping to a bitcoin address, or a dedicated namespace can be used if prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).

* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one to the other is really easy
- bitcoin could even allow registration of names by sending an RPC request to namecoin

* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin, you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined with an https url (so, using DNS or HTTP(S) is not a major problem anymore if the first point of entry is really secure and configurable [and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol is extensible


Examples of possible registered names in namecoin with the "personal namespace" (with the "p/" prefix) :

* An individual person with well known public addresses :
"p/khal":
{
    "email": "khal@dot-bit.org",
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* Another individual person with well known public addresses :
"p/khal@dot-bit.org":
{
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* A merchant accepting payments in bitcoin, namecoin, paypal or othercoin (to show you how the whole namespace could be used) :
"p/mymerchant.com":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
        "cert": "https://payto.mymerchant.com/certificate.pem",
    },
    "namecoin": {
        "url": "https://payto.mymerchant.com/namecoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
    },
    "paypal": "xxxxxx@yyyyyyyyy.zzz",
    "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

* A merchant with a public address, an url to generate custom addresses and a domain name (not sure if this case is really usefull, maybe as fallback)
"p/mymerchant2":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
        "dns": "_bitcoin.payto.mymerchant.com",
        "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    }
}


* How to use it in bitcoin ?

Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?


Here is how things would be processed when people put an address to pay to in the bitcoin client :

* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and "p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and "p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy


Le 15/12/2011 20:59, theymos a écrit : 
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.

------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Best Regards,
Khalahan
http://dot-bit.org/
--------------060608040301030600010103--