[announce] Namecoin - a distributed naming system based on Bitcoin

[vinced]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Namecoin is a naming system based on bitcoin with a few modifications.  It is inspired by the bitdns discussion and recent failures of the DNS.

The quick facts:

* This is a new blockchain, separate from the main Bitcoin chain
* Name/value pairs are stored in the blockchain attached to coins
* Names are acquired through new transaction types - new, first-update and update
* Names expire after 12000 blocks unless renewed with an update
* No two unexpired names can be identical
* Block validation is extended to reject transactions that do not follow the above rules
* The code is here: https://github.com/vinced/namecoin

Initially, two name spaces are defined - DNS and personal.  The DNS name space is targetted towards a new distributed TLD, possibly .bit.

Here is how you can help:

* Compile and run namecoind.
* Do some mining.  The starting difficulty is 512, so CPU mining is still viable.
* We need proxies, browser plugins and DNS servers created to act as a bridge between Namecoin and users.

!Vince
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCgAGBQJNqyz4AAoJEJz+siqjwOQOnU0IAKKIZk13qKFaXkVH0JSDkyov
AQNaYpML/017DrLBI+xsQLp88CpRQx10e/JUoqLV1UbJ+uB3hBtAUi05O03/U0wE
Q4tQbLOhnWt+ZcYYPXL1pf6fIo7clBV47ncuBLWWnRCkjLIF2kj9rs5muFFxgN4G
K6gq79xZFxwg2b2gGWaM5ZHlC513AQW68o+YpebofGyRM2yQHBrWCb0g/PC8bjsX
n33Xe4Ch0fj+3Apfc2Yv71+P6DLZU8oxL9xo8/FbG856wHdr2LEoh7Io4PiDIiYU
Y81MxvlpGDYKLomSsiI3w5stMyIVYEV6RNt4BVBND0x2n2XKFB8c2SmCHahnnkU=
=px0m
-----END PGP SIGNATURE-----

[kiba]

So we should start polling people whether or not to reward you with the bounty award?

[vinced]

So we should start polling people whether or not to reward you with the bounty award?

I would be happy to apply for the bounty award after people have reviewed the design and code.

[eMansipater]

Haven't looked at the code, but would it be correct to assume mining grants rights to acquire a DNS entry?

[elggawf]

Am I reading it right that one would have to spend 50NC to register a name, then 50NC every 12,000 to keep it updated? So 50NC every 120,000 minutes?

What is the format of value?

Had to make some changes to get it to compile on FreeBSD, but I think I have it running (though it doesn't appear to be generating yet):

{"result":{"version":32100,"balance":0.00000000,"blocks":0,"connections":3,"proxy":"","generate":true,"genproclimit":-1,"difficulty":1.00000000,"hashespersec":0,"testnet":false,"keypoololdest":1303090416,"paytxfee":0.00000000,"errors":""},"error":null,"id":"curltest"}

I can see it connected to IRC along with several other hosts, but I have blocks=0.

[kiba]

Can't figure out how to get it to use wx 2.9 rather than 2.8.

[kiba]

How much does it cost to register a name?

[fabianhjr]

No, the discussion is to not fragment the network.
Together we stand, divided we fall.

It should be integrated into the Bitcoin clients.

As far as registry it should work like this:
-You always get 50 domains per block.
-Each domain can be changed to any other(boring.bit -> serious.bit) as long as the other isn't occupied.
-It can be updated at any time without needing to mine a block. You may pay a fee for faster processing.
-It may be transfer from an address to another just as Bitcoins.

[theymos]

As I said in the BitDNS discussion, hard-limiting the network-wide number of registrations will fail. If 50 domains are produced per block, then what happens when more than 50 domains are needed per 10 minutes? Prices will become uncompetitive and the system will lose popularity.

[dust]

Fails to compile with gcc 4.5.2

Code:

hook.cpp: In function ‘int GetDefaultPort()’:
hook.cpp:116:20: error: new declaration ‘int GetDefaultPort()’
net.h:14:23: error: ambiguates old declaration ‘short unsigned int GetDefaultPort()’

Making the return type consistent between files fixes the error.

[dust]

Has anyone else got this working? There is no namecoind target in the makefile, so i built bitcoind.  My daemon is currently sitting at 0 blocks and doesn't recognize calls such as name_list and name_scan.

[da2ce7]

As I said in the BitDNS discussion, hard-limiting the network-wide number of registrations will fail. If 50 domains are produced per block, then what happens when more than 50 domains are needed per 10 minutes? Prices will become uncompetitive and the system will lose popularity.

True,  the BitDNS must have some sort of load balancing, so that domains remain cheap, but are not spammed.

I would like domains to be like Bitcoin address, You can make as many as you like, but only ones that have coins on them are worth anything.

[John Kirk]

As I said in the BitDNS discussion, hard-limiting the network-wide number of registrations will fail. If 50 domains are produced per block, then what happens when more than 50 domains are needed per 10 minutes? Prices will become uncompetitive and the system will lose popularity.

The point here is to validate ownership of names, not restrict the total number of names or in the system to an arbitrary upper limit, right?

If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks?  That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated?  POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.

[theymos]

The point here is to validate ownership of names, not restrict the total number of names or in the system to an arbitrary upper limit, right?

If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks?  That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated?  POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.

There's a lower limit to the number of minutes between blocks. Below that, latency plays too big a factor. So you'd want to adjust the block reward and block size instead of the block frequency.

That would probably result in prices going too low, where there are more domain requests than the network is actually capable of fulfilling. Supply/demand can't be calculated automatically: there needs to be a market. If a separate chain is used, miners need to sell domain space. I'd just put the data in the Bitcoin chain and rely on Bitcoin's transaction fees, though.

[John Kirk]

I agree that generating a fixed amount of new names per hour is not going to work.  The cost of entry into the system would quickly become prohibitive, when you consider the number of new names created daily worldwide in the DNS system.

Also, as you said, the system will need scarcity to some degree to prevent spammers.  But, not too much to prevent the cost of registering from skyrocketing, which I believe will happen with the current fixed rate of generation.

Maybe we could we make the monetary reward tied into the number of new name requests within the block somehow.  For example, allow any number of new name requests in every block.  However, vary the reward given to the miner based on this to be slightly smaller.  So, if there are 100 new name requests, then give the miner 99 coins as a reward, and require these coins to be spent on renewals.  So, there will be a slight amount of competition for the coins, as there aren't enough generated for everyone to renew.

[da2ce7]

Also, as you said, the system will need scarcity to some degree to prevent spammers.  But, not too much to prevent the cost of registering from skyrocketing, which I believe will happen with the current fixed rate of generation.

People should be paying for the upkeep of the network, not the domains themselves.  I think that a 'hosting fee' or taking money through registration and updating records would be the best manner.  Just like we have transaction fees on the Bitcoin network for the long-term 'upkeep.'

If a spammer makes 1000000 domains, the spammer must pay for the upkeep of 1000000 domains, this will be very expensive.  The domains themselves are unlimited (there are an unlimited number of possible strings), so in-themselves they shouldn't have a price.

Think: are you charged for creating a Bitcoin address? No!  You are charged for USING your bitcoin address.

[John Kirk]

I just had a thought.

Suppose we allow any number of transactions per block.  Each transaction costs a fixed amount (say, 1 coin), which vanishes once the transaction completes.

The reward for the miner is variable according to the following formula:

Reward = C + S*T

Where C is a constant value, say 10.  S is also a constant value less than 1.0, say 0.95, and T is the sum of the transaction fees within the block.

If there are very few transactions within the block, we can assume that the cost of transactions is too high, and the C term will tend to add more coins into the economy than the S*T term removes.  Conversely, if there are very many transactions within the block, then the S*T term will tend to remove more coins from the economy than C adds.

Over time, an equilibrium should result.

[asdf]

___brainstorm___

why can't this work just like bitcoin, with the following additions:

transactions can include an extra parameter of a domain name as well as any namecoins.

you transfer/update a domain by "spending" it do an address with an appropriate fee for the miner. To update/renew a domain you spend it to your own address. To transfer you spend it to someone else's.

claim new domains by transferring a domain that isn't taken to one of you own addresses. Problem: how to stop spam-claimers.

domains expire after not being transfered for a year and are then claimable by anyone.

miners sell their generated namecoins (probably for bitcoins :-) ) and people can use them to get their domain encoded in the blockchain.

people can trade namecoins just like bitcoins.

[da2ce7]

___brainstorm___

why can't this work just like bitcoin, with the following additions:

transactions can include an extra parameter of a domain name as well as any namecoins.

you transfer/update a domain by "spending" it do an address with an appropriate fee for the miner. To update/renew a domain you spend it to your own address. To transfer you spend it to someone else's.

claim new domains by transferring a domain that isn't taken to one of you own addresses. Problem: how to stop spam-claimers.

domains expire after not being transfered for a year and are then claimable by anyone.

miners sell their generated namecoins (probably for bitcoins :-) ) and people can use them to get their domain encoded in the blockchain.

people can trade namecoins just like bitcoins.

The problem with this system is that the miners get as many domains as they want for free.  We need to use transaction scripts with a 3rd party escrow that releases the funds slowly.  This will create a 'reputation' based system, where escrows that are respected can charge greater fees/have a more respected 'domain chain'.

[John Kirk]

Personally, it seems to me that the currency generated by the namecoin system should be focused on maintaining the network.  The name registry is the primary aspect here.  The coin generation exists to support it.

I just realized that my previous reward formula has a problem: R = C + S*T will indeed reach an equilibrium, but this is not a whole lot better than just a flat 50 per block, as it will tend toward a constant average over time.

However, if we add another term to the formula that takes into account the number of expirations within the block, then we might be able to fix that problem.  How's this:

Reward = C + S*T + B*E

Here, C, S, and T have their earlier meanings.  B is a constant greater than 1.0, say 1.05.  E is the number of expirations that are in the block, which are costless transactions inserted by the miner that note when a name has not been renewed within the required time.

As noted earlier, the C + S*T part of the formula will tend to pull the average number of transactions per block toward an equilibrium.  But, the B*E term will inflate the currency if there are a large number of expirations, indicating that the cost of maintaining a name is too high.