dmp1ce
|
|
April 20, 2011, 01:42:49 PM |
|
Anybody registered a domain yet?
At least here, nameindex.dat seems empty and name_scan returns []. I keep generating blocks and the wallet is getting bigger (in bytes) but the balance is stuck at 0. I couldn't find anything in the design doc about this either. Shouldn't the balance go up? Names won't be able to be created until blocks mature into 50 Namecoins. I believe it takes 120 blocks after the block is found for it to mature. At least that is the way it is in Bitcoin. After 121 or maybe 133, you should start seeing names from name_scan.
|
|
|
|
Garrett Burgwardt
|
|
April 20, 2011, 01:52:42 PM |
|
When there's a windows client I'll be all over this.
|
|
|
|
mizerydearia
|
|
April 20, 2011, 03:11:05 PM |
|
How about using the entire system as the base database for dns?
To get domains(including subdomains) miners need a block, each block yields 50 domains. Have no increase in difficulty at all such that getting a block requires... something like a days work for a GPU. If someone wants more than 50 domains in a day then they need to put more miners to work. This way there is no arbitrary limit on the number of domains created per day, the only limit being CPU power, which costs money(this will prevent too much domain squating.
Also domains have an expiry of something like 100 blocks, so in order to keep ownership of a domain the owner must continue mining, such that I don't know, a decent gpu can hold onto 10,000 domains(more?less?).
Transactions being 2 things, first transfering the ownership of a domain, second, adding an IP to a domain. This way dns servers can use the block chain as the domain db.
Finally have the entire blockchain re-written every 100 blocks or something(I don't know that this is even possible). As we don't need to know the entire transaction history of every domain so every 100 blocks or so we throw away all the transaction records and just keep a record of who owns what domain associated with which ip address. Hopefully that would keep the block chain at manageable levels.
You could also increase the level of work required to aquire a specific domain, such that shorter domains require more work, longer domains require less work. But I don't know how you would implement this in the above. Or at all
This does not tie into the current bitcoin blockchain at all (and it should't anyway).
This seems like a LOT of unnecessary power consumption costs
|
|
|
|
memvola
|
|
April 20, 2011, 05:34:07 PM |
|
By the way, will 1023 bytes suffice for the zone file? I checked now and I have files much larger. What is the spec exactly?
|
|
|
|
dmp1ce
|
|
April 20, 2011, 06:22:57 PM |
|
I could be wrong, but I think the names in Namecoin will be used to reference another nameserver where you will keep your zone files. Here is a short snipet from the domain name registrar article on wikipedia: Registration of a domain name establishes a set of SOA records in the DNS servers of the parent domain, indicating the IP address (or domain name) of DNS servers that are authoritative for the domain. However, this merely provides a reference for how to find the domain's records – not the actual domain data.
|
|
|
|
memvola
|
|
April 20, 2011, 06:46:40 PM Last edit: April 20, 2011, 07:14:09 PM by memvola |
|
Registration of a domain name establishes a set of SOA records in the DNS servers of the parent domain, indicating the IP address (or domain name) of DNS servers that are authoritative for the domain. However, this merely provides a reference for how to find the domain's records – not the actual domain data. Interesting. Is it the right approach though? User would need to set up or register to a separate DNS server, which is somewhat against the purpose I presume? Maybe it isn't though... Mapping into the .bit domain is simply: d/xyz => xyz.bit . The value is interpreted as a zone specification.
Above is the quote from the design document. Since multiple records with the same name is out of the question (isn't it?), maybe records could reference eachother? And be gzipped by default? It would be pretty nice if a decision is made, albeit temporary, so that we can set up a DNS server and start using the system right away. EDIT: Oh, I just realized that these approaches are not mutually exclusive. Correct me if I'm wrong but user has the choice to supply SOA-only or a more elaborate zone file. And how about encoding? Plain text would be wasteful.
|
|
|
|
dmp1ce
|
|
April 20, 2011, 07:06:38 PM |
|
Tell me if this sounds right:
The domain name resolver needs to either have the Namecoin database to query directly or know where to find a Namecoin root-level DNS (which don't currently exist) for information on where to find the full zone file. Either way, there will need to be code on the client side to tell the domain name resolver how to find .bit domain information.
|
|
|
|
memvola
|
|
April 20, 2011, 07:24:21 PM |
|
Tell me if this sounds right:
The domain name resolver needs to either have the Namecoin database to query directly or know where to find a Namecoin root-level DNS (which don't currently exist) for information on where to find the full zone file. Either way, there will need to be code on the client side to tell the domain name resolver how to find .bit domain information.
Why the client side + a root-level DNS? A DNS server could do all that. Or you could do it on purely client-side, in which case a root-level DNS wouldn't be contacted? I was thinking along the lines of setting up several DNS servers, which would resove .bit domains, maybe together with OpenNIC and such. Geeks could run their own resolvers, which I'm guessing would be namecoind itself? (Edited for clarification.)
|
|
|
|
dmp1ce
|
|
April 20, 2011, 07:39:16 PM |
|
I was thinking along the lines of setting up several DNS servers, which would resove .bit domains, maybe together with OpenNIC and such. Geeks could run their own resolvers, which I'm guessing would be namecoind itself?
That sounds terrific! I think you have a better grasp on the solution than I do.
|
|
|
|
vinced (OP)
Newbie
Offline
Activity: 23
Merit: 34
|
|
April 21, 2011, 02:28:04 AM |
|
I added a FAQ to the code repository: https://github.com/vinced/namecoin/blob/master/FAQ.mdIt answers some of the questions brought up in this thread and more. @memvola @dmp1ce - a DNS bridge would be great. Yes, the value should be a zone file, and can have either addresses or a DNS delegation. I don't know if DNS delegation works well behind Tor, so maybe addresses are better. @dmp1ce - thank you for the offer. I'd be ever grateful if you could register the name d/v . This would end up being v.bit after the DNS piece is available. A couple of design questions to think about: - right now the expiration is set to 12000 blocks, or about 3 months. Is that too short? Renewal will be automatic if your client is connected. - should the TLD be .bit or something that ICANN is unlikely to ever register, like .b, .n or even .-b?
|
|
|
|
dmp1ce
|
|
April 21, 2011, 02:53:40 AM |
|
I added a FAQ to the code repository: https://github.com/vinced/namecoin/blob/master/FAQ.mdIt answers some of the questions brought up in this thread and more. @memvola @dmp1ce - a DNS bridge would be great. Yes, the value should be a zone file, and can have either addresses or a DNS delegation. I don't know if DNS delegation works well behind Tor, so maybe addresses are better. @dmp1ce - thank you for the offer. I'd be ever grateful if you could register the name d/v . This would end up being v.bit after the DNS piece is available. A couple of design questions to think about: - right now the expiration is set to 12000 blocks, or about 3 months. Is that too short? Renewal will be automatic if your client is connected. - should the TLD be .bit or something that ICANN is unlikely to ever register, like .b, .n or even .-b? Thank you for writing the software and explaining how it works. I'd be happy to reserve d/v for you. I had some questions about the faq though, it says: Q: How long are names good for?
A: You have to execute an update on a name every 12000 blocks (normally about three months), or it expires. There is no network fee for updates.
Does that mean I can spend all of my NC on domains and not have to worry about leaving leftovers for updates? I thought that updates cost 50 NC but decreased over time. About the design questions, I have not a clue. I think 3 months is reasonable, especially if it auto renews. Why do we have to decide on the TLD? Is it possible that Namecoin names could specify the TLD to use as well?
|
|
|
|
|
ryepdx
|
|
April 21, 2011, 03:34:06 AM |
|
About the design questions, I have not a clue. I think 3 months is reasonable, especially if it auto renews. Why do we have to decide on the TLD? Is it possible that Namecoin names could specify the TLD to use as well?
I second the question.
|
|
|
|
kiba
Legendary
Offline
Activity: 980
Merit: 1024
|
|
April 21, 2011, 06:03:31 AM |
|
Had anybody able to run the bitcoind and namecoind?
It seems that bitcoind is instead reading the configuration file in .namecoin rather than .bitcoin?
|
|
|
|
memvola
|
|
April 21, 2011, 02:23:05 PM |
|
It seems that bitcoind is instead reading the configuration file in .namecoin rather than .bitcoin?
That is kinda odd, I'd get it if it was the other way around. Are you sure they aren't hard linked or anything? I'm running both by the way, with RPC servers on. I suggest you run namecoind as a different user, just in case. About the design questions, I have not a clue. I think 3 months is reasonable, especially if it auto renews. Why do we have to decide on the TLD? Is it possible that Namecoin names could specify the TLD to use as well?
I second the question. Yes I also think 3 is OK, but 6 would be much better. Can we meet third way and make it 4? Regarding TLD: There is also the question about TLD's other than .bit (or whatever is accepted as the default). However I think putting TLD in the name is kinda against the established architecture. I think it needs to be part of the name specification, not the name itself.
|
|
|
|
dmp1ce
|
|
April 21, 2011, 03:14:44 PM |
|
Regarding TLD: There is also the question about TLD's other than .bit (or whatever is accepted as the default). However I think putting TLD in the name is kinda against the established architecture. I think it needs to be part of the name specification, not the name itself.
So, if we wanted .bit and .web for instance we would run two block chain networks, one for .bit and one for .web? I can see how that might fit the established architecture better, but why not use the additional namespace in Namecoin to define additional TLDs? The name server software could simply ignore names that specified a TLD that were invalid. I am probably showing my ignorance here, but why couldn't Namecoin be the index for TLDs that currently aren't used? I think it would be interesting if there was a TLD block chain, and then owners could have entire TLDs to sell if they wanted to. Maybe the owner could run a block chain of their own to sell their TLD space, or they could sell in a more central manor. Then you could get urls like "web" Or "web.help", or simply "bitcoin". Is this a possibility or am I crazy?
|
|
|
|
memvola
|
|
April 21, 2011, 03:48:39 PM Last edit: April 21, 2011, 04:05:22 PM by memvola |
|
Regarding TLD: There is also the question about TLD's other than .bit (or whatever is accepted as the default). However I think putting TLD in the name is kinda against the established architecture. I think it needs to be part of the name specification, not the name itself.
So, if we wanted .bit and .web for instance we would run two block chain networks, one for .bit and one for .web? I can see how that might fit the established architecture better, but why not use the additional namespace in Namecoin to define additional TLDs? The name server software could simply ignore names that specified a TLD that were invalid. I wasn't talking about two block chains, but rather using application specifiers. I guess, in effect, it's the same thing as you say. Now, d/ can be the default domain specifier, no need to change it, and in the future we could add dw/ for .web for instance. On a different note, I'm struggling to understand what the deal is here: $ namecoind getinfo { "version" : 32100, "balance" : 99.90000000, "blocks" : 193, "connections" : 16, "proxy" : "", "generate" : false, "genproclimit" : -1, "difficulty" : 512.00781274, "hashespersec" : 0, "testnet" : false, "keypoololdest" : 1303282246, "paytxfee" : 0.00000000, "errors" : "" }
$ namecoind name_list [ ..., { "name" : "d/q", "value" : "x", "expires_in" : 11973 }, ... ]
exp@erik ~/namecoin $ namecoind name_firstupdate d/q 2xxxxxxxxxxxxxxxx0 value error: {"code":-4,"message":"Error: The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."}
exp@erik ~/namecoin $ namecoind getinfo { "version" : 32100, "balance" : 50.47000000, "blocks" : 193, "connections" : 16, "proxy" : "", "generate" : false, "genproclimit" : -1, "difficulty" : 512.00781274, "hashespersec" : 0, "testnet" : false, "keypoololdest" : 1303282246, "paytxfee" : 0.00000000, "errors" : "" }
$ namecoind name_firstupdate d/bet 0xxxxxxxxxxxxxxxx0 value bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxb
$ namecoind getinfo { "version" : 32100, "balance" : 51.04000000, "blocks" : 194, "connections" : 16, "proxy" : "", "generate" : false, "genproclimit" : -1, "difficulty" : 512.00781274, "hashespersec" : 0, "testnet" : false, "keypoololdest" : 1303282246, "paytxfee" : 0.00000000, "errors" : "" }
I'm guessing d/q collided, because someone else had already made the first update. Was it why I had an "x" in my name list? So where did that 49.43 NCs go? And where did the last 0.57 NC come from? And why didn't I pay 50 for the second name? I'm such a confused panda... EDIT: Couldn't get d/bet either. I'm guessing d/q was taken but not updated yet. That's why there was the error and I lost 50 coins. d/bet was already updated so nothing happened. These are my guesses... I still don't know why I'm missing 50 NCs though...
|
|
|
|
dmp1ce
|
|
April 21, 2011, 04:07:22 PM |
|
I'm guessing d/q collided, because someone else had already made the first update. Was it why I had an "x" in my name list? So where did that 49.43 NCs go? And where did the last 0.57 NC come from? And why didn't I pay 50 for the second name? I'm such a confused panda...
I'm not sure what happened, but surely there are some bugs to work out in the system. It looks like what happened is you had a collision with d/q. I show that someone else has that name as well. BTW, you can do a complete scan of all claimed names using name_scan. About not having to pay 50 for the second name, possibly the system detected that it took your NC by mistake when you tried to get d/q ? If you are generating blocks then you will get some "transaction fees" from people running name_new and name_update. I believe the "transaction fees" are one NC cent or 0.01 NC and the "network fees" are 50 NC right now and only occur during name_firstupdate commands. I'll try to test registering the d/q when I get some more NC. I spent it all already.
|
|
|
|
dmp1ce
|
|
April 21, 2011, 04:17:33 PM |
|
Yep, I had the exact same thing happen to me when I tried to register d/q. I lost 50 NC and got the same error.
|
|
|
|
memvola
|
|
April 21, 2011, 04:21:44 PM Last edit: April 21, 2011, 04:39:11 PM by memvola |
|
About not having to pay 50 for the second name, possibly the system detected that it took your NC by mistake when you tried to get d/q ?
Hehe. Well, I couldn't get the second either. I'm guessing it was already in name_scan and I didn't see it, that's why it didn't give me an error. d/q wasn't when I tried to update (though I'm not sure). It could as well be the other way around. (It must be the other way around, since you also got the same behavior, but it makes less sense IMO.) Yep, I had the exact same thing happen to me when I tried to register d/q. I lost 50 NC and got the same error.
I'm hoping there was a fork of some sorts and we'll get back our NCs when the network gets rid of it. We need a block explorer, quick! Have you tried restarting with namecoind -rescan?
|
|
|
|
|