Author

Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 105. (Read 597092 times)

hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
Nefario:

Holding block difficulty constant would cause the blocks-per-hour rate to vary wildly, which is undesirable for technical reasons (as opposed to policy reasons, which are more debatable).

Holding domain difficulty (as measured in hashes per domain) constant would result in domains becoming exponentially cheaper with advances in computing hardware. This is probably not what we want.

The entire point of having raising or falling difficulty is to limit the number of blocks per hour, to keep it steady. This is to ensure a steady rate of (in bitcoins case) new bitcoins are created, in our case it's new domains. We've already seen that we don't want to limit the number of domains created at any time.

I'm sorry, I don't know what are the technical reasons against varying blocks per hour.

Yes it would get cheaper to create more domains, and it would get cheaper to hold more domains, this is not a bad thing as the number of domais will increase condsiderably as the system grows, why would we want it to get more expensive to hold onto and get more domains over time?

At that point all the lower level domains will be taken, and only longer ones remaining, the relative value of new domains decreases with their length (to an entent, there are exceptions). With the increase in computing power, and the resultant lowering of cost would reflect the lower value of longer names.
newbie
Activity: 28
Merit: 0
Nefario:

Holding block difficulty constant would cause the blocks-per-hour rate to vary wildly, which is undesirable for technical reasons (as opposed to policy reasons, which are more debatable).

Holding domain difficulty (as measured in hashes per domain) constant would result in domains becoming exponentially cheaper with advances in computing hardware. This is probably not what we want.
hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
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).

newbie
Activity: 28
Merit: 0
It seems to me that what we want is for the cost of registering or renewing a single domain to remain roughly constant.

Costs in the real world are rarely constant.  Free world, free market.

We can still make reasonable estimates. Moore's law has been relatively stable for some time, and it seems likely to continue for the forseeable future.
member
Activity: 98
Merit: 13
It seems to me that what we want is for the cost of registering or renewing a single domain to remain roughly constant. The only variable we should take into account is then the cost in dollars of computation. I'd suggest a simple fixed deflation rate calibrated to the Moore's-law predicted curve. (But be careful about gotchas like GPU mining.)

Costs in the real world are rarely constant.  Free world, free market.

newbie
Activity: 28
Merit: 0
It seems to me that what we want is for the cost of registering or renewing a single domain to remain roughly constant. The only variable we should take into account is then the cost in dollars of computation. I'd suggest a simple fixed deflation rate calibrated to the Moore's-law predicted curve. (But be careful about gotchas like GPU mining.)
sr. member
Activity: 308
Merit: 250
I wouldn't say it's superficial, I worry that it could screw with an existing bitcoin installation.

Oops, forgot about that. I thought you were talking about things in the makefile, names of the binaries, etc.
member
Activity: 98
Merit: 13
-The network must still not be fragmented
Remember: Together we stand, divided we fall.

1. Multiple block chains are inevitable.

2. Let's not shoehorn every block chain application into bitcoin.  Let bitcoin be a currency, and not a DNS system.  The currency users will appreciate this.

sr. member
Activity: 392
Merit: 251
No, the discussion is to not fragment the network.
Together we stand, divided we fall.

A lot of people that might not care about Bitcoin do care about a decentralized DNS system so I don't think this new network will have a big impact on Bitcoin's hashrate.

And I agree with what has been said about the constant 50 per block reward, it would be too little if it goes mainstream and probably too much right now. Something like 1 + difficulty/x might be better.
sr. member
Activity: 294
Merit: 250
Apparently I inspired this image.
I would suggest that a full conversion from bitcoin to namecoin at least be done before this moves any further.

Honestly I think that's a bit superficial yet - is anyone even able to get it to generate blocks?

I wouldn't say it's superficial, I worry that it could screw with an existing bitcoin installation.
sr. member
Activity: 308
Merit: 250
I would suggest that a full conversion from bitcoin to namecoin at least be done before this moves any further.

Honestly I think that's a bit superficial yet - is anyone even able to get it to generate blocks?
sr. member
Activity: 294
Merit: 250
Apparently I inspired this image.
To fix the compile error, just change the declaration of 'int GetDefaultPort()' to 'short unsigned int GetDefault Port()' in hook.cpp

However, while I applaud this effort, it is not ready for release. I did a quick grep of the source and noticed that the name 'bitcoin' is still used throughout *including for config files and the like*.

I would suggest that a full conversion from bitcoin to namecoin at least be done before this moves any further.
sr. member
Activity: 322
Merit: 250
Do The Evolution
Ok, because of what was stated I will slightly change my opinion on this.
-The network must still not be fragmented
-You may get a domain by paying a fee to the miner. This would probably by a 10 BTC fee which would avoid spam. It will decrease as needed.
-Each domain can be changed to any other(boring.bit -> serious.bit) as long as the other isn't occupied. You must pay a fee for the update lesser than the one to create a new domain.
-It can be updated at any time without needing to mine a block. You may pay a fee for faster processing.(Subject to miner)
-It may be transfer from an address to another just as Bitcoins. You may pay a fee for faster processing.(Subject to miner)

Remember: Together we stand, divided we fall.
Make a pull request of the main Bitcoin client.
member
Activity: 69
Merit: 10
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.

I'm having the same trouble.  Is namecoin connecting to the bitcoin IRC channel because I'm getting a lot of "IRC got join" messages?   My debug.log is also returning this error:

Code:
ERROR: ConnectInputs() : 9d07b96a9f mapTransactions prev not found 6a2ec09d75
ERROR: AcceptToMemoryPool() : ConnectInputs failed 9d07b96a9f

BTW, I changed the location of the data directory namecoin uses because I ran it once on a computer that had already run bitcoin and it seemed to corrupt the database.  I couldn't start bitcoin again until I removed the database files and allowed them to rebuild.

https://github.com/dmp1ce/namecoin/commit/267092456f58e4ecbd7fddf95e13e0042152f341

member
Activity: 65
Merit: 10
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.
legendary
Activity: 1222
Merit: 1016
Live and Let Live
___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'.
hero member
Activity: 527
Merit: 500
___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.
member
Activity: 65
Merit: 10
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.
legendary
Activity: 1222
Merit: 1016
Live and Let Live
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.
member
Activity: 65
Merit: 10
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.
Jump to: