phelix
Legendary
Offline
Activity: 1708
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2013, 08:11:42 AM |
|
[...] 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/HowToRegisterAndConfigureBitDomainsHigher name_op feesWith 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_
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 88
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2013, 09:12:45 AM |
|
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/HowToRegisterAndConfigureBitDomainsHigher name_op feesWith 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.
|
COINVALIDATION IS SLAVERY NAMECOIN IS FREEDOM BOYCOTT COINVALIDATION BUY NAMECOINS
|
|
|
snailbrain
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2013, 03:31:24 PM |
|
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-qthttps://github.com/namecoin-qt/namecoin-qt
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2013, 10:21:32 PM |
|
getinfo still says 355 but not a big deal
|
|
|
|
snailbrain
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2013, 10:35:31 PM |
|
getinfo still says 355 but not a big deal
just updated the zip wrong, fixed it thanks
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 12:11:43 AM |
|
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
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 12:23:41 AM |
|
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
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 12:36:16 AM |
|
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.
|
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 10:40:33 AM |
|
It's a sticky one ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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_prefixesLowercase n is already taken also ... pick a base58 character and go with it?
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 10:53:21 AM |
|
Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?
|
|
|
|
snailbrain
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 01:22:13 PM |
|
It's a sticky one ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) yeh it seems so ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) will leave like this for now.. and see what as many peoples thoughts are (Nelisky?)
|
|
|
|
snailbrain
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 01:25:16 PM |
|
Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?
not me ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) but a "few" people do.. doublec? (think that's how you spell his name)
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 05:38:14 PM |
|
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 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) but a "few" people do.. doublec? (think that's how you spell his name)
|
|
|
|
midnightlightning
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 68
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 09:22:14 PM |
|
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): 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: 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
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 10:02:49 PM |
|
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.
|
|
|
|
khal
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2013, 10:48:47 PM Last edit: June 06, 2013, 05:47:09 PM by 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 : 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/436f571d41cc53844d482eeef0069a3ca94e08f8https://bitcointalk.org/index.php?topic=43719.0https://bitcointalk.org/index.php?topic=43465.0 (first post erased...) So, after block 19200, go back 2016 instead of 2015.
|
|
|
|
virtualmaster
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 07:04:37 AM |
|
When will come out the .new domains for Namecoin ?
|
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 08:10:15 AM |
|
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
Legendary
Offline
Activity: 1807
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2013, 10:50:19 AM |
|
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
|
|
|
|
|