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

[phelix]

[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]

Does this really work? I thought I tried and it did not... Would be nice if it did.

You are right, phelix. A name_update of an expired name doesn't work even though I am the owner of the expired name. However, the name_list command still displays my out-of-date names as expected.

What worries me a little is that a name_update is completely free of charge. This leaves the door wide open for massive spamming.
The results of a few fee tests (after doing a settxfee 0.00):
name_new: 0.01 + 0.0005
name_firstupdate: 0.0005
name_update: 0.0000

txfees depend on priority voodoo of your coins. If you have your coins lying around for a year you may not have to pay anything.

also on fees:
https://dot-bit.org/HowToRegisterAndConfigureBitDomains

Higher name_op fees
With higher fees for name operations there is a problem of what to do with them. Distributing to a single miner does not work very well because miners can then register at a discount / resell. Distributing to several miners is too complicated and creates lots of dust (small outputs). Depositing coins that can later be redeemed is not really a fee in my eyes. The only working solution I see is destroying coins which a lot of people are afraid of.

Maybe we can accept destruction of value if we agree to keep a minimum block reward of 1NMC forever? (waiting for the storm)

[spartacus_]

txfees depend on priority voodoo of your coins. If you have your coins lying around for a year you may not have to pay anything.

also on fees:
https://dot-bit.org/HowToRegisterAndConfigureBitDomains

Higher name_op fees
With higher fees for name operations there is a problem of what to do with them. Distributing to a single miner does not work very well because miners can then register at a discount / resell. Distributing to several miners is too complicated and creates lots of dust (small outputs). Depositing coins that can later be redeemed is not really a fee in my eyes. The only working solution I see is destroying coins which a lot of people are afraid of.

Maybe we can accept destruction of value if we agree to keep a minimum block reward of 1NMC forever? (waiting for the storm)

Block reward shouldn't be changed.
Fee destruction should remain but the amount should decrease over time eventually to null.
Mining reward should remain almost constant (slightly decreasing over time. This way the transaction and registration fee rewarded to the miners will compensate the decreasing block reward.

[snailbrain]

How's this for a plan? I need the following RPC calls added:
- importprivkey
- dumpprivkey
- importaddress (from codeshark's PR, I can dig the number if needed)
- listunspent
- createrawtransaction
- decoderawtransaction
- getrawtransaction
- sendrawtransaction
- signrawtransaction
- signmessage
- verifymessage
- listaddressgroupings (I can live without this one, but it is useful)

Added:
- createrawtransaction
- decoderawtransaction
- getrawtransaction
- sendrawtransaction
- signrawtransaction

should all be done, any chance you can double check all are working?

windows exe
http://www.mediafire.com/folder/3aa8ukj7v6m5d/Namecoin-qt

https://github.com/namecoin-qt/namecoin-qt

[bitpop]

getinfo still says 355 but not a big deal

[snailbrain]

getinfo still says 355 but not a big deal

just updated the zip wrong, fixed it thanks

[marcus_of_augustus]

snailbrain : I was just testing the "dumpprivkey" on namecoin-qt and it has outputted keys with leading characters 2xxx?

I was expecting wallet import format leading characters 5xxx ... something may have been missed in the translation?

[snailbrain]

snailbrain : I was just testing the "dumpprivkey" on namecoin-qt and it has outputted keys with leading characters 2xxx?

I was expecting wallet import format leading characters 5xxx ... something may have been missed in the translation?

does importing it not work?
will test asap

[marcus_of_augustus]

snailbrain : I was just testing the "dumpprivkey" on namecoin-qt and it has outputted keys with leading characters 2xxx?

I was expecting wallet import format leading characters 5xxx ... something may have been missed in the translation?

does importing it not work?
will test asap

I didn't test importing, it may well work if the same format has been used there also ... it was that I was expecting them to be in the bitcoin WIF, leading char 5, such that the same privkey can be used interchangeably between namecoin and bitcoin wallets. That may be a task for a spearate translation tool ... it just wasn't what I was expecting. I would go for same privkey format as bitcoin if it was purely my decision.

[snailbrain]

i tested it.. working fine it seems (dumpprivkey and importprivkey)

we used Nelisky's patch.. (which gives 2xxx)

https://github.com/namecoin-qt/namecoin-qt/commit/95ca4f8dc800a203f65613afe5c9c79894d6c6a7
Before that it was 5xxx.

let me know thoughts

[marcus_of_augustus]

i tested it.. working fine it seems (dumpprivkey and importprivkey)

we used Nelisky's patch.. (which gives 2xxx)

https://github.com/namecoin-qt/namecoin-qt/commit/95ca4f8dc800a203f65613afe5c9c79894d6c6a7
Before that it was 5xxx.

let me know thoughts

It's a sticky one 

Pros and cons either way I think. Clearly there is increased chance for confusion using same prefix as bitcoin priv key, but if we use the same then there is no need for an intermediate tool to convert formats when moving shared bit/namecoin priv keys between wallets.

Looks like the prefix 2 is already reserved for testnet script hash so there is potential for confusion/conflict there. https://en.bitcoin.it/wiki/List_of_address_prefixes

Lowercase n is already taken also ... pick a base58 character and go with it?

[bitpop]

Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?

[snailbrain]

i tested it.. working fine it seems (dumpprivkey and importprivkey)

we used Nelisky's patch.. (which gives 2xxx)

https://github.com/namecoin-qt/namecoin-qt/commit/95ca4f8dc800a203f65613afe5c9c79894d6c6a7
Before that it was 5xxx.

let me know thoughts

It's a sticky one 

yeh it seems so

will leave like this for now.. and see what as many peoples thoughts are (Nelisky?)

[snailbrain]

Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?

not me

but a "few" people do.. doublec? (think that's how you spell his name)

[bitpop]

Thanks, I need to fork bytecoin and I have a bounty up.

Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?

not me

but a "few" people do.. doublec? (think that's how you spell his name)

[midnightlightning]

Okay, here's a technical question; I've got an issue trying to get my namecoin port to validate the block at height 24192. That's a point where the difficulty target changes (24192 % 2016 = 0), and it looks to me like the difficulty moved incorrectly, and yet it's in the blockchain as valid.

The logic (as I understand it) for the difficulty changes are: [old target] * [actual time] / [expected time] = [new target].

Here's the old target (what block 24191 has) and the new target (what block 24192 has):

Code:

old target: 000000000000b269000000000000000000000000000000000000000000000000 (bits of 0x1b00b269)
new target: 0000000000006b32b10000000000000000000000000000000000000000000000 (bits of 0x1a6b32b1)

But here's what my math arrives at:
The timestamp on block 24191 is 1319487998. Block 22176 (2016 blocks before 24192, the first one with the difficulty bits of 0x1a6b32b1) has a timestamp of 1318761282. The difference of those two (actual time spent) is 726716, which makes [actual]/[expected] = 0.600790343915344. Hence I get a new target of:

Code:

my target:  0000000000006b2fe50000000000000000000000000000000000000000000000 (bits of 0x1a6b2fe5)

Close, but not quite. Taking the new difficulty that apparently is valid, I get a ratio of 0.6008515185394, arriving at an actual timestamp of 1319488072. That's 74 seconds after the timestamp of 24191. My retargeting math has worked for all the previous retargets, so why did this one go wonky? Was there some different logic in place for this block round that allowed a slightly different difficulty retarget? Is this a rounding error (after multiplying the old target by the actual time spent, do I need to truncate it before dividing it out)?

[marcus_of_augustus]

Nelisky : what's the logic behind your patch that has the priv key prefix "2xxx" ? Is it done this way anywhere else? Why not use the "5xxx" prefix for interchangeability with bitcoin priv keys?

Thanks if you can shed some light.

i tested it.. working fine it seems (dumpprivkey and importprivkey)

we used Nelisky's patch.. (which gives 2xxx)

https://github.com/namecoin-qt/namecoin-qt/commit/95ca4f8dc800a203f65613afe5c9c79894d6c6a7
Before that it was 5xxx.

let me know thoughts

[khal]

That's 74 seconds after the timestamp of 24191. My retargeting math has worked for all the previous retargets, so why did this one go wonky? Was there some different logic in place for this block round that allowed a slightly different difficulty retarget? Is this a rounding error (after multiplying the old target by the actual time spent, do I need to truncate it before dividing it out)?

Block 22175 is 74s before block 22176 (time of block 22175 = 1318761208).

This code may be responsible of that :

Code:

main.cpp: GetNextWorkRequired line 671
    // Go back the full period unless it's the first retarget after genesis. Code courtesy of ArtForz

    int nBlocksBack = nInterval-1;
    if(pindexLast->nHeight >= hooks->GetFullRetargetStartBlock() && ((pindexLast->nHeight+1) > nInterval))
        nBlocksBack = nInterval;

It is related to a bug known as "retarget hole"/timetravel due to merged mining :
https://github.com/namecoin/namecoin/commit/436f571d41cc53844d482eeef0069a3ca94e08f8
https://bitcointalk.org/index.php?topic=43719.0
https://bitcointalk.org/index.php?topic=43465.0 (first post erased...)

So, after block 19200, go back 2016 instead of 2015.

[virtualmaster]

When will come out the .new domains for Namecoin ?

[nelisky]

Nelisky : what's the logic behind your patch that has the priv key prefix "2xxx" ? Is it done this way anywhere else? Why not use the "5xxx" prefix for interchangeability with bitcoin priv keys?

Thanks if you can shed some light.

I'm a little ashamed to say I think I jumped the gun with this change... I thought I was changing the address version and I now, on closer inspection, see I changed the private key prefix... oops.

There is no reason not to use bitcoin's version (128) instead for the private key, but I had some problem that prompt me to fix is like this, and now I can't remember what that was.

Feel  free to revert that but do try to do a newaddress -> dumpprivkey | new wallet | -> importprivkey to make sure it is working as expected.

[snailbrain]

Nelisky : what's the logic behind your patch that has the priv key prefix "2xxx" ? Is it done this way anywhere else? Why not use the "5xxx" prefix for interchangeability with bitcoin priv keys?

Thanks if you can shed some light.

I'm a little ashamed to say I think I jumped the gun with this change... I thought I was changing the address version and I now, on closer inspection, see I changed the private key prefix... oops.

There is no reason not to use bitcoin's version (128) instead for the private key, but I had some problem that prompt me to fix is like this, and now I can't remember what that was.

Feel  free to revert that but do try to do a newaddress -> dumpprivkey | new wallet | -> importprivkey to make sure it is working as expected.

reverted patch and seems to test working:

now start with 5xx