Bitcoin Forum
April 18, 2024, 06:19:51 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 ... 102 »
  Print  
Author Topic: [announce] Namecoin - a distributed naming system based on Bitcoin  (Read 594415 times)
dmp1ce
Member
**
Offline Offline

Activity: 69
Merit: 10


View Profile WWW
April 18, 2011, 11:18:19 AM
 #21

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


BTCmon - Support great bitcoin apps
1713464391
Hero Member
*
Offline Offline

Posts: 1713464391

View Profile Personal Message (Offline)

Ignore
1713464391
Reply with quote  #2

1713464391
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713464391
Hero Member
*
Offline Offline

Posts: 1713464391

View Profile Personal Message (Offline)

Ignore
1713464391
Reply with quote  #2

1713464391
Report to moderator
1713464391
Hero Member
*
Offline Offline

Posts: 1713464391

View Profile Personal Message (Offline)

Ignore
1713464391
Reply with quote  #2

1713464391
Report to moderator
1713464391
Hero Member
*
Offline Offline

Posts: 1713464391

View Profile Personal Message (Offline)

Ignore
1713464391
Reply with quote  #2

1713464391
Report to moderator
fabianhjr
Sr. Member
****
Offline Offline

Activity: 322
Merit: 250


Do The Evolution


View Profile
April 18, 2011, 02:07:29 PM
 #22

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.

brocktice
Sr. Member
****
Offline Offline

Activity: 292
Merit: 250


Apparently I inspired this image.


View Profile WWW
April 18, 2011, 02:15:05 PM
 #23

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.

http://media.witcoin.com/p/1608/8----This-is-nuts

My #bitcoin-otc ratings: http://bitcoin-otc.com/viewratingdetail.php?nick=brocktice&sign=ANY&type=RECV

Like my post? Leave me a tip: 15Cgixqno9YzoKNEA2DRFyEAfMH5htssRg
elggawf
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
April 18, 2011, 02:55:34 PM
 #24

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?

^_^
brocktice
Sr. Member
****
Offline Offline

Activity: 292
Merit: 250


Apparently I inspired this image.


View Profile WWW
April 18, 2011, 03:17:28 PM
 #25

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.

http://media.witcoin.com/p/1608/8----This-is-nuts

My #bitcoin-otc ratings: http://bitcoin-otc.com/viewratingdetail.php?nick=brocktice&sign=ANY&type=RECV

Like my post? Leave me a tip: 15Cgixqno9YzoKNEA2DRFyEAfMH5htssRg
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile
April 18, 2011, 04:12:24 PM
 #26

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.
xf2_org
Member
**
Offline Offline

Activity: 98
Merit: 13


View Profile
April 18, 2011, 04:19:17 PM
 #27

-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.

elggawf
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
April 18, 2011, 05:56:05 PM
 #28

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.

^_^
Delia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
April 19, 2011, 01:04:27 AM
 #29

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.)
xf2_org
Member
**
Offline Offline

Activity: 98
Merit: 13


View Profile
April 19, 2011, 01:09:17 AM
 #30

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.

Delia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
April 19, 2011, 01:19:50 AM
 #31

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.
Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
April 19, 2011, 01:25:21 AM
 #32

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).


PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Delia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
April 19, 2011, 01:30:39 AM
 #33

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.
Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
April 19, 2011, 01:45:09 AM
 #34

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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Delia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
April 19, 2011, 01:51:22 AM
 #35

Too low blocks per hour increases the wait time for confirmation; too high causes network latency to become an issue.
Nefario
Hero Member
*****
Offline Offline

Activity: 602
Merit: 512


GLBSE Support support@glbse.com


View Profile WWW
April 19, 2011, 01:57:21 AM
 #36

Too low blocks per hour increases the wait time for confirmation; too high causes network latency to become an issue.

Then there does need to be a hard limit on the number of new domains created per hour.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Delia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
April 19, 2011, 02:05:13 AM
 #37

Too low blocks per hour increases the wait time for confirmation; too high causes network latency to become an issue.

Then there does need to be a hard limit on the number of new domains created per hour.

I recommend non-constant domains per block. Let block generation only be used for maintaining a verifiable history (i.e., demonstrating that you registered a domain "first"); actual domain generation can be keyed to an entirely independent proof-of-work challenge.
vinced (OP)
Newbie
*
Offline Offline

Activity: 23
Merit: 34


View Profile
April 19, 2011, 05:36:37 AM
 #38

Sorry for the missing makefile.  I added it and also changed the default directory to .namecoin .  The excutable produced is
Code:
namecoind
.

If your bitcoin blockchain got corrupted, just copy your wallet.dat to a new data directory and download the chain again.

@elggawf @kiba only the initial registration costs 50NC.  The 50NC value drops by 50% every two months.  It is just a way to slow down initial registration spam.  Longer term, only transaction fees matter.

@fabianhjr there was a discussion about this on the forum, and the major players did not want to have a name/values in the main chain.  The namecoin code was designed to require as little change as possible to the bitcoin master.  I will send a pull request to bitcoin for the hooks.  See the namecoin hooks branch if interested.

@dust fixed, thanks!
mgiuca
Newbie
*
Offline Offline

Activity: 25
Merit: 7


View Profile
April 19, 2011, 05:38:33 AM
 #39

Great idea. How are you proposing you "pay" for a domain name?

If Namecoin has the exact same concept of Bitcoin inside its blocks, but completely separate from Bitcoin, and you need to spend those coins to create or update DNS entries, that will stop spammers. But how do you get "namecoins"?

If you can only get them by mining, then only the miners will be able to register domains. As we have seen with Bitcoin, we can't all be miners. Eventually, the computational power will shift to the big GPU miners and normal people won't be able to participate. This is OK with Bitcoin, because there are other ways to get Bitcoins besides mining them. But with Namecoin that will mean we'll need a separate mtgox and CoinPal and all that, for turning real money into Namecoin just so we can buy domains. And we'll have to get a Namecoin economy going, distinct from Bitcoin. This seems like a huge amount of hassle just to register domains. (Effectively, just to avoid spam -- since we aren't trying to get an economy going, just provide a way to register names and prevent people from going through and registering, for example, all 1-4 letter names in one go.)

Perhaps instead of using Bitcoin-style currency to register a domain, we can leverage the Bitcoin idea of computation time as a cost. But unlike Bitcoin, we don't let the cost of registering a domain go up when more people join.

Basically, creating a transaction requires that you solve a hash, much like the Bitcoin block algorithm but entirely separate from that. In order to create a Bitcoin transaction, it is currently free. Signing a block is not free, but creating the transaction requires no computational overhead: you just send it into the cloud. What if, for creating a domain name transaction, there is a computational overhead. Say that I want to register the domain "example.nmc". I have to create a transaction:
{
    domain: 'example.nmc',
    nonce: 'RUpaYclaNkVihUSXoEXDDqWBLEngewRTxbFdLlVrNwfxjuqzZOBuVliQgHxBcCYk'
}

Now it turns out that the string 'example.nmc:RUpaYclaNkVihUSXoEXDDqWBLEngewRTxbFdLlVrNwfxjuqzZOBuVliQgHxBcCYk' hashes (with SHA256) to '0000c7a12b8499add9fdef0de04307a8dbfa056d29fe811e6a92478e8a87d5ce', a number beginning with 16 zero bits. My machine does about 16 khashes per second, so it will take me on average 4.1 seconds to find a nonce starting with 16 zero bits. But say we bump it up to 26 bits. On my machine this will take, on average, 69 minutes to find.

Let's say that all domain registrations must come with a nonce that, when salted with the domain (and possibly a bunch of other metadata so it's unique for each transaction) and hashed, the hash starts with 26 zero bits. Now domain registration is free, but it takes an hour on average. The spammers (at 16 khash/sec) can only register one domain per hour. Then we can have the Namecoin system completely separate from Bitcoin.

Now there are problems with this approach. It is still CPU-biased, so anyone with a lot of computing power can register domains very quickly. Unlike Bitcoin, which stays just as hard as CPUs get better, this will get easier. So maybe it isn't a correct approach at all. Just throwing it out there though.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
April 19, 2011, 05:43:26 AM
 #40

Great idea. How are you proposing you "pay" for a domain name?

If Namecoin has the exact same concept of Bitcoin inside its blocks, but completely separate from Bitcoin, and you need to spend those coins to create or update DNS entries, that will stop spammers. But how do you get "namecoins"?

Use bitcoin.

Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 ... 102 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!