is it just a a bitcoin clone using another blockchain or what is it?
also give me a OS X binary so i can run this thing
Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 100. (Read 596107 times)
April 24, 2011, 10:56:16 AM
could someone explain exactly what is this?
is it just a a bitcoin clone using another blockchain or what is it?
also give me a OS X binary so i can run this thing
is it just a a bitcoin clone using another blockchain or what is it?
also give me a OS X binary so i can run this thing
April 24, 2011, 05:16:14 AM
Generation
The code is identical to bitcoin, with the amount halved every four years. Some people seem to prefer constant generation? Reasons?
My only thought was that the amount of money in the system can be a limiting factor on the number of domains possible. I have not done the math to see if this could be the case. Or if it is always the case that domains are limited by the block size.The code is identical to bitcoin, with the amount halved every four years. Some people seem to prefer constant generation? Reasons?
I guess it is not a big deal because plenty of coins will be generated within the next 8 to 12 years, but I'm wondering what I'll happen later if there are no more extra coins to afford to buy new domains? Again I suppose the rate could be changed to constant if this becomes a problem, so it isn't a big problem.
It likely makes NC rarer than BTC however since NC is getting clobbered by the name_firstupdate commands. It may end up that NC is more valuable than BTC or even the domain names themselves. I just hadn't thought that the system would intend to make the Namecoin currency valuable in the same way Bitcoin does, but I think it could work.
April 24, 2011, 01:53:48 AM
I am disappointed in not seeing a great deal of activity in your repository. I know it's a voluntary project and all...
Are you busy or something?
Are you busy or something?
April 23, 2011, 10:34:31 PM
DNS
I've been thinking more about representing values. A zone file doesn't seem like a good solution after all. For one, you can't do DNS delegation if you are behind Tor. So I'm proposing JSON with optional gzip encoding. Example:
{'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}
first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain. In the third case, you translate foo.name.bit to foo.bar.com and resolve that. It's close enough to delegation and works behind Tor. We can extend this for mail exchange and other things as the need arises.
I've been thinking more about representing values. A zone file doesn't seem like a good solution after all. For one, you can't do DNS delegation if you are behind Tor. So I'm proposing JSON with optional gzip encoding. Example:
{'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}
first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain. In the third case, you translate foo.name.bit to foo.bar.com and resolve that. It's close enough to delegation and works behind Tor. We can extend this for mail exchange and other things as the need arises.
I couldn't quite figure out what all the use cases could be. I'll give it a try, but take it with a grain of salt.
In the majority of cases, people (I assume from skimming through the other threads) would want it to work as a domain name registry. It would be a drop-in replacement for Wikileaks people (or me) for instance. For these cases, both public and local (namecoind?) DNS bridges would forward queries to the specified primary master server. In effect, it's identical to adding the below zone statement to named.conf:
Code:
zone "example.bit" {
type forward;
forward only;
forwarders { ns1.examplehost.net; ns2.examplehost.net; };
};
So, whatever the format, they will supply two name servers and nothing else. In the Tor case, it's up to the exit node to resolve example.bit. I don't think it would be feasible to try to forward the request from behind Tor (I tried it through the proxy without success, but I might be missing something). I'm assuming namecoind would also act as a DNS server. Please correct me because I'm making a wild guess here.
Some people might want it to act as a master server by supplying a zone file. Below is an example.
Code:
$TTL 1W
$ORIGIN example.bit.
@ IN SOA localhost. hostmaster.example.bit. (
2011042222
8H
4H
1W
1D )
TXT "We could abuse some types of records."
NS localhost.
A 74.125.113.147
AAAA 2001:4860:0:1001::68
MX 10 mail99.mailer.bit.
www CNAME @
mail CNAME mail99.mailer.bit.
onion CNAME eqt5g4fuenphqinx.onion.
This should almost be the same in effect to your Json example, so both formats would do the deed. I'm rather confused by your example though, because if namecoind will indeed act as a DNS server, to my knowledge, it should forward the foo.bar.com query through the proxy. Maybe even namecoind will be a proxy itself?
I put the onion record there as a naive example but it wouldn't/shouldn't work that way. It shouldn't even be in the IN class. I'm not sure there is a way that would cover all non-ip networks. For freenet for instance, http redirection could work. For tor/i2p, a local resolver could catch query results and treat them appropriately. Again, if there will be a namecoin proxy, it might solve these issues.
I propose resolving .bit, .b and .n, recommending that web sites expect virtual hosts under all three, but that people refer to .bit URLs for now. This gives us some fallbacks if ICANN decides to use .bit for something else. So if you register d/foo, you normally use https://foo.bit, but foo.n and foo.b also work.
@memvola - just saw your post about TLDs and you bring up some interesting ideas. Maybe start with my proposal above and add TLDs later if it seems like the right thing?
@memvola - just saw your post about TLDs and you bring up some interesting ideas. Maybe start with my proposal above and add TLDs later if it seems like the right thing?
I get the reasoning but wouldn't it be confusing? It could be after many years that ICANN decides to use .bit and by then, every record would need to use each and every TLD, just in case. Maybe we need to find something ICANN wouldn't pick.
As for adding new TLDs later, I think it's the sanest choice. But this in turn gives some more authority to the developers, that's why I think some people don't like the idea.
@memvola if you get a name clash, the losing transaction becomes a zombie and the wallet thinks you have less coins to spend. This will be fixed soon, sorry that it ties up your NC.
There's also the cases where a clash hasn't occured but names don't show in name_scan. I can give a more detailed report if it's not the same issue.
April 23, 2011, 05:28:37 PM
Status
As I'm writing this, we are at block 559. Generation is about 10 minutes per block so the difficulty is right on target. 181 domains registered.
Economics
Some good points were raised regarding the economics of the system. Here are my thoughts. As the code is now the network fees become negligible in a couple of years and only the regular transaction fees remain. Miners will charge transaction fees based on the cost of processing and competition.
Beyond that, some names are more valuable than others because of marketing reasons. Some miners might try to charge more to update valuable names. Some names will be registered early and sold in marketplaces.
It seems that all these dynamics will result in some kind of equilibrium, but it is difficult to tell what it will be.
It's not clear how miners will choose tx fees. The maximum that a domain holder might need to spend to renew their domain is the equivalent to the average miner revenue from a block. This comes out to 50 NC + 5000 times the average domain tx fee if there are 5000 tx per block. This is how much it would cost them to generate a block themselves. The owner of sex.bit might experience this.
As to the total number of names supported by the system, max bitcoin block size is now 1MB, average tx size might be 200, renewal period is 12000 blocks and assume 2 updates per period. This gives 30M domains supported. I feel this is too low and we'll have to raise the block size, either now or later. Should we target 10 billion names?
DNS
I've been thinking more about representing values. A zone file doesn't seem like a good solution after all. For one, you can't do DNS delegation if you are behind Tor. So I'm proposing JSON with optional gzip encoding. Example:
{'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}
first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain. In the third case, you translate foo.name.bit to foo.bar.com and resolve that. It's close enough to delegation and works behind Tor. We can extend this for mail exchange and other things as the need arises.
We do have to decide on a TLD strategy so people know what URL to tell their users. Otherwise there will be inconsistent implementations and the end-users will get confused.
I propose resolving .bit, .b and .n, recommending that web sites expect virtual hosts under all three, but that people refer to .bit URLs for now. This gives us some fallbacks if ICANN decides to use .bit for something else. So if you register d/foo, you normally use https://foo.bit, but foo.n and foo.b also work.
@memvola - just saw your post about TLDs and you bring up some interesting ideas. Maybe start with my proposal above and add TLDs later if it seems like the right thing?
Generation
The code is identical to bitcoin, with the amount halved every four years. Some people seem to prefer constant generation? Reasons?
@da2ce7 the initially high network fee will slow early domain squatting.
@memvola if you get a name clash, the losing transaction becomes a zombie and the wallet thinks you have less coins to spend. This will be fixed soon, sorry that it ties up your NC. As to the network fee, it was 50 at genesis and is already a bit lower. It will be 25 after about 2 months.
@dmp1ce yes, updates are costless. Also, if you update before the 12 are up, the tx will stick around until the 12th block comes. It's no problem.
@0x6763 good point. However, if there's a clash with ICANN, different users will see different sites for the same name. Wouldn't it be better if clashes are avoided, at least until the system is stronger? 21 million NC will be created and some are lost to the decaying network fee.
@gavinandresen - I agree with your analysis. There's no other discussion of the economics, other than this thread.
@xf2_org @noagendamarket - Namecoin is pretty close to what Satoshi described. What significant differences do you see? He did mention a renewal fee, but I don't see why that would be useful in addition to the tx fee set by the miner.
As I'm writing this, we are at block 559. Generation is about 10 minutes per block so the difficulty is right on target. 181 domains registered.
Economics
Some good points were raised regarding the economics of the system. Here are my thoughts. As the code is now the network fees become negligible in a couple of years and only the regular transaction fees remain. Miners will charge transaction fees based on the cost of processing and competition.
Beyond that, some names are more valuable than others because of marketing reasons. Some miners might try to charge more to update valuable names. Some names will be registered early and sold in marketplaces.
It seems that all these dynamics will result in some kind of equilibrium, but it is difficult to tell what it will be.
It's not clear how miners will choose tx fees. The maximum that a domain holder might need to spend to renew their domain is the equivalent to the average miner revenue from a block. This comes out to 50 NC + 5000 times the average domain tx fee if there are 5000 tx per block. This is how much it would cost them to generate a block themselves. The owner of sex.bit might experience this.
As to the total number of names supported by the system, max bitcoin block size is now 1MB, average tx size might be 200, renewal period is 12000 blocks and assume 2 updates per period. This gives 30M domains supported. I feel this is too low and we'll have to raise the block size, either now or later. Should we target 10 billion names?
DNS
I've been thinking more about representing values. A zone file doesn't seem like a good solution after all. For one, you can't do DNS delegation if you are behind Tor. So I'm proposing JSON with optional gzip encoding. Example:
{'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}
first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain. In the third case, you translate foo.name.bit to foo.bar.com and resolve that. It's close enough to delegation and works behind Tor. We can extend this for mail exchange and other things as the need arises.
We do have to decide on a TLD strategy so people know what URL to tell their users. Otherwise there will be inconsistent implementations and the end-users will get confused.
I propose resolving .bit, .b and .n, recommending that web sites expect virtual hosts under all three, but that people refer to .bit URLs for now. This gives us some fallbacks if ICANN decides to use .bit for something else. So if you register d/foo, you normally use https://foo.bit, but foo.n and foo.b also work.
@memvola - just saw your post about TLDs and you bring up some interesting ideas. Maybe start with my proposal above and add TLDs later if it seems like the right thing?
Generation
The code is identical to bitcoin, with the amount halved every four years. Some people seem to prefer constant generation? Reasons?
@da2ce7 the initially high network fee will slow early domain squatting.
@memvola if you get a name clash, the losing transaction becomes a zombie and the wallet thinks you have less coins to spend. This will be fixed soon, sorry that it ties up your NC. As to the network fee, it was 50 at genesis and is already a bit lower. It will be 25 after about 2 months.
@dmp1ce yes, updates are costless. Also, if you update before the 12 are up, the tx will stick around until the 12th block comes. It's no problem.
@0x6763 good point. However, if there's a clash with ICANN, different users will see different sites for the same name. Wouldn't it be better if clashes are avoided, at least until the system is stronger? 21 million NC will be created and some are lost to the decaying network fee.
@gavinandresen - I agree with your analysis. There's no other discussion of the economics, other than this thread.
@xf2_org @noagendamarket - Namecoin is pretty close to what Satoshi described. What significant differences do you see? He did mention a renewal fee, but I don't see why that would be useful in addition to the tx fee set by the miner.
April 23, 2011, 09:40:34 AM
You won't get the name until at least 12 blocks after the block name_new went through on. You should get it if you didn't get an error. I have gotten all of mine.
I missed two of them even though I got no error and no one else had attempted to get the same ones. Apart from the other failures I've mentioned before.
April 22, 2011, 09:30:01 PM
P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.
How?
See satoshi's posts (recently reposted and collected by noagendamarket).
April 22, 2011, 08:19:32 PM
P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.
How?
1. Is there a full spec somewhere?
I was just toying with bind and value fields for domain entries. The idea is to start using these domains right away through a DNS bridge. I'm not an expert on DNS nor bitcoin but here are my random thoughts...
First, I don't know if the value field can or should be binary. I'd insist on expecting gzipped zone files by default, but we can also detect that from the header even under base64 (which isn't extremely economical). If we can agree that zone files could be used for everything (i2p, tor, freenet, some future wireless mesh system) then this could be the standard. Otherwise we also need a header. I for one haven't figured how simple delegation would work with a zone file. Maybe a different specification would be more appropriate.
DNS servers can report arbitrary data (at least as CNAME or TXT records), but resolvers seem to expect IP, so I was unable to successfully use a DNS server to map names to, for instance, .onion adresses. I'm hoping someone less ignorant about resolvers will come up with an idea. Is introducing a class other than IN a good idea? There could also be privacy concerns in the case of a DNS bridge.
Also, I'm guessing the zone file will need to know the TLD in order to work properly under an ordinary DNS server. So we also need to decide on the default TLD. dmp1ce's proposal/question about arbitrary TLDs should be answered at this point. What are the options?
- A default TLD, like .bit, dictated by the system.
- No default TLD, current registered names act as TLDs. Also arbitrary TLDs are allowed, like d/example.weird
- One default TLD, and arbitrary TLDs allowed in one of these forms: d/example.weird, dweird/example, d/example/weird, d/weird.example, ?
- Multiple TLDs, dictated by the specification. There is currently only one, but developers may decide to introduce new ones via the application specifier.
- ?
April 22, 2011, 07:21:09 PM
Who will be the first to run a BTC/NC exchange?
Though FWIW I think NameCoin is more an experiment, and a P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.
April 22, 2011, 02:52:29 PM
Who will be the first to run a BTC/NC exchange?
Though FWIW I think NameCoin is more an experiment, and a P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.
April 22, 2011, 02:47:12 PM
Currently mining. I think i control >50% of the network
April 22, 2011, 11:18:29 AM
My turn to be the newbie: Is there a high-level discussion of the economics of NameCoin or DNS in general somewhere? What is the scare resource that needs to have a price attached?
My half-baked thoughts:
Seems like domain names are not the scarce resource; CPU power available to process transactions is the scarce resource. So it seems to me simply not allowing any free transactions, allowing an arbitrary number of "new domain" and "domain transfer" transactions with arbitrary fees attached, and allowing the mining nodes to decide which transactions to accept into their blocks and which to drop will create the "right" number of domain names at the "right" price.
Any individual, well-known domain name is a scarce resource. "google.namecoin" is worth more than "xblkje4klj21.namecoin"... but if I want to get the google.namecoin domain name from google (or a domain squatter), and google or the domain squatter is willing to keep paying the (minimal) NameCoin renewal transaction fee, then I can just offer them cash or bitcoins (or NameCoins) to transfer the domain to me.
My half-baked thoughts:
Seems like domain names are not the scarce resource; CPU power available to process transactions is the scarce resource. So it seems to me simply not allowing any free transactions, allowing an arbitrary number of "new domain" and "domain transfer" transactions with arbitrary fees attached, and allowing the mining nodes to decide which transactions to accept into their blocks and which to drop will create the "right" number of domain names at the "right" price.
Any individual, well-known domain name is a scarce resource. "google.namecoin" is worth more than "xblkje4klj21.namecoin"... but if I want to get the google.namecoin domain name from google (or a domain squatter), and google or the domain squatter is willing to keep paying the (minimal) NameCoin renewal transaction fee, then I can just offer them cash or bitcoins (or NameCoins) to transfer the domain to me.
April 22, 2011, 09:23:20 AM
- should the TLD be .bit or something that ICANN is unlikely to ever register, like .b, .n or even .-b?
That's the risk with making a top-down decision for a system wide TLD instead of letting people choose their own TLDs and taking the risk individually.
The approach I'm going to take (unless I decide I like your project enough to halt development on mine) is to not set a global TLD for this system, but let users register their own TLDs. The resolver would by default give priority to ICANN TLDs over those from the distributed system (to make the transition smoother for normal people who might not be quick to stop using com/net/org, etc). Users would be able to change a setting if they wanted to ignore all ICANN TLDs, or choose certain ones to use/ignore. All of the DNS information for TLDs and sub-domains would be stored in a DHT, and the DNS settings on the user's machine would point to a locally running DNS server which acts as the gateway to the DNS info stored in the DHT. I'm not going to choose a TLD for everyone else, and TLD conflicts between the system and ICANN can be resolved by the users of the system, without relying on me to fix them.
The decaying network fee idea is interesting...I'm not sure what I think about it, yet. How many namecoins will the system create? Is there a set limit like bitcoin (I hope so), or will they be generated forever? Are the namecoins destroyed by the network fee ever replaced (not that I think they need to be)?
April 22, 2011, 07:23:56 AM
Now you guys see why I'm so nice to n00bs--I know that at some point, inevitably, I will be one again.
I feel like a n00b almost all the time, no matter how hard I try to not be one. More questions--do namecoins show in "getinfo" before they mature, or after? And if after, how does one know they are mature and what happens if you try to register a name before your coins mature?
Namcoins show up 120 blocks after the block is found. As far as I know, they cannot be spent before then. If you try to run "name_new" or "name_firstupdate" without enough Namecoins (as shown in "getinfo") then you'll get an error. 
April 21, 2011, 05:37:02 PM
More questions--do namecoins show in "getinfo" before they mature, or after? And if after, how does one know they are mature and what happens if you try to register a name before your coins mature?
April 21, 2011, 05:18:01 PM
Forever, or on the BitCoin curve with that amount reduced every two years?
I think forever. Developer have to verify.
April 21, 2011, 05:02:57 PM
Forever, or on the BitCoin curve with that amount reduced every two years?
I think forever. Developer have to verify.
April 21, 2011, 05:00:36 PM
Methinks that it only generate 50 namecoin every ten minute.
Forever, or on the BitCoin curve with that amount reduced every two years? April 21, 2011, 03:32:21 PM
4. Can someone explain the economics here--if this thing runs on the same distribution curve as BitCoin (with a finite total of Namecoins) then doesn't that cap the total entries at 19,000,000/0.01, and if it has an infinite total then doesn't that wipe out the mining incentive?
Methinks that it only generate 50 namecoin every ten minute. However, the FAQ said name registration will destroy namecoins. April 21, 2011, 02:53:52 PM
Four questions:
1. Is there a full spec somewhere?
2. Why does this default to the same RPC port as the bitcoin client?
3. Has the NameCoin protocol been properly designed to allow cross-mining?
4. Can someone explain the economics here--if this thing runs on the same distribution curve as BitCoin (with a finite total of Namecoins) then doesn't that cap the total entries at 19,000,000/0.01, and if it has an infinite total then doesn't that wipe out the mining incentive?
Now you guys see why I'm so nice to n00bs--I know that at some point, inevitably, I will be one again.
1. Is there a full spec somewhere?
2. Why does this default to the same RPC port as the bitcoin client?
3. Has the NameCoin protocol been properly designed to allow cross-mining?
4. Can someone explain the economics here--if this thing runs on the same distribution curve as BitCoin (with a finite total of Namecoins) then doesn't that cap the total entries at 19,000,000/0.01, and if it has an infinite total then doesn't that wipe out the mining incentive?
Now you guys see why I'm so nice to n00bs--I know that at some point, inevitably, I will be one again.
Jump to: