<unnamed>

Public Key

npub1euw92v2lmlflea24tgns69r4gxwfknh3ufj0ata70hrk7jxkhgws0l06dn

Profile Code

nprofile1qqsv78z4x90al5lu74245fcdz365r8ymfmc7ye8747l8m3m0frtt58gprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv3q93xr

Publishing to

relay.snort.social

Last Notes

2023-06-07 02:48:23 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Namecoin is a decentralized system designed to map names to other things in a fully decentralized way, not limited to .bit usage. It is easily connectable to Bitcoin and allows for extensibility.
📝 Original message: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 at dot-bit.org",
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}
* Another individual person with well known public addresses :
"p/khal at 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 at 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 at dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2 at bitcoin : will conflict with names already containing a @
- mymerchant2 at 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 at dot-bit.org
-> RPC to namecoin for "p/khal at dot-bit.org"
-> json processing for "p/khal at 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 13/12/2011 14:06, Gavin Andresen a écrit :
> I agree with Mike Hearn and Christian Decker-- paying to
> 'somebody at foo.com' should become, behind the scenes, a HTTPS query to
> https://foo.com/something. If you just want to (say) donate to
> eff.org, then paying to '@eff.org' aught to work nicely.
>
> And if namecoin ever takes off you'll pay to 'somebody at foo.bit'.
>
> It seems to me that if it was DNS-based, the address should be
> something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
> people will setup and run a custom DNS server just to support bitcoin
> payments.
>
--
Best Regards,
Khalahan
http://dot-bit.org/

2023-06-07 02:43:45 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Bitcoin proposals for aliases have limitations, including centralization, reliance on HTTPS and CA, and limited domain name usage. Namecoin integration is complex but effective.
📝 Original message:The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> is not
infinite, here are their problems :
- FirstBits : centralized
- DNS TXT Records : DNSSEC is required to have a minimum of security,
limits usage to engineers, limits usage to some domain names (i won't be
able to use a gmail address for example, because i don't control the
gmail.com domain)
- Server Service (DNS + a daemon) : Same as DNS TXT records
- HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able
to check the full certificate chain and access a list of up-to-date
certificate authorities (installed on the OS or provided with bitcoin).
And don't forget the CA model is not 100% reliable (several CA hacked
this year + possible government control...).
- IP Transactions : /This proposal seeks to enable DNS lookups for IP
transactions/ => same as above
I know that providing a namecoin daemon with bitcoin is not the lighter
solution, but, if a better one existed i guess it would have already
been integrated into bitcoin... (see in what state is my first attempt
with the HTTPS proposal : Send payments to emails, urls and domains in
GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened
this pull request April 20, 2011/)
So, what's next ?
Le 16/12/2011 20:54, slush a écrit :
> Khalahan, honestly, using namecoin for aliases is (for me) clean
> example of over-engineering. I mean - it will definitely work if
> implemented properly. I played with a namecoin a bit (as my pool was
> the first 'big' pool supporting merged mining), but I think there's
> really long way to provide such alias system in namecoin and *cleanly
> integrate it with bitcoin*. Don't forget that people who want to do
> lookup need to maintain also namecoin blockchain with their bitcoin
> client. It goes against my instinct of keeping stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into
> my fork of Electrum client. I did it in 15 minutes, it works as
> expected, it does the job and the implementation is really
> transparent, becuase implementation is 20 lines of code. There's no
> magic transformation, no forced "?handle=" parameters or whatever. And
> I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
> <https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True>
>
> And everybody can do the same in their clients, in their merchant
> solutions, websites or whatever. Everybody can do HTTPS lookup. But
> try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So
> far I understand it as some teoretic concept which is not supported by
> anything else right now. Give it few years until it matures and then
> add IIBAN alias to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make
> aliases as easy as possible, so everybody can implement it in their
> own solution and thus practially remove the need of using standard
> bitcoin addresses for normal users. Using some superior technology,
> which is hard to implement or even understand won't solve the
> situation, because it will ends up with some reference implementation
> in standard client only and nobody else will use it.
>
> slush
--
Best Regards,
Khalahan
http://dot-bit.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/cb3fc4b4/attachment.html>

2023-06-07 02:43:32 UTC

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Namecoin is a decentralized system designed to map names to other things, such as public bitcoin addresses or URLs, and is not limited to .bit usage. It is proven technology, has no single point of failure, and is easily connectable to bitcoin.
📝 Original message: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 at dot-bit.org",
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}
* Another individual person with well known public addresses :
"p/*khal at 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 at 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 at dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2 at bitcoin : will conflict with names already containing a @
- mymerchant2 at 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 at dot-bit.org
-> RPC to namecoin for "p/khal at dot-bit.org"
-> json processing for "p/khal at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Best Regards,
Khalahan
http://dot-bit.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/e4feca94/attachment.html>