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.
Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 104. (Read 596130 times)
April 18, 2011, 12:56:05 PM
Oops, forgot about that. I thought you were talking about things in the makefile, names of the binaries, etc.
April 18, 2011, 11:19:17 AM
-The network must still not be fragmented
Remember: Together we stand, divided we fall.
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.
April 18, 2011, 11:12:24 AM
No, the discussion is to not fragment the network.
Together we stand, divided we fall.
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.
April 18, 2011, 10:17:28 AM
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.
April 18, 2011, 09:55:34 AM
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?
April 18, 2011, 09:15:05 AM
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.
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.
April 18, 2011, 09:07:29 AM
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.
-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.
April 18, 2011, 06:18:19 AM
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
April 18, 2011, 03:55:53 AM
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.
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.
April 18, 2011, 03:40:47 AM
___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.
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'.
April 18, 2011, 03:35:27 AM
___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.
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.
April 18, 2011, 02:55:08 AM
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.
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.
April 18, 2011, 02:52:05 AM
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.
April 18, 2011, 02:24:07 AM
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.
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.
April 18, 2011, 01:49:05 AM
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.
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.
April 18, 2011, 01:25:13 AM
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.
April 17, 2011, 11:58:09 PM
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.
April 17, 2011, 10:52:37 PM
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.
April 17, 2011, 10:29:55 PM
Fails to compile with gcc 4.5.2
Making the return type consistent between files fixes the error.
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.
April 17, 2011, 10:08:29 PM
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.
Jump to: