Pages:
Author

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

member
Activity: 68
Merit: 10
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)?
legendary
Activity: 2912
Merit: 1060
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

but a "few" people do.. doublec? (think that's how you spell his name)
legendary
Activity: 1807
Merit: 1020
Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?

not me Sad

but a "few" people do.. doublec? (think that's how you spell his name)
legendary
Activity: 1807
Merit: 1020
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  Smiley



yeh it seems so Cheesy

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

legendary
Activity: 2912
Merit: 1060
Somewhat related, does anyone know how to patch bytecoin to merged mine just like namecoin did?
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
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  Smiley

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?
legendary
Activity: 1807
Merit: 1020
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
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
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.
legendary
Activity: 1807
Merit: 1020
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
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
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?
legendary
Activity: 1807
Merit: 1020
getinfo still says 355 but not a big deal


just updated the zip wrong, fixed it thanks
legendary
Activity: 2912
Merit: 1060
getinfo still says 355 but not a big deal
legendary
Activity: 1807
Merit: 1020

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
member
Activity: 88
Merit: 10

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.
legendary
Activity: 1708
Merit: 1020

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

legendary
Activity: 1807
Merit: 1020

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


This is correct. I agree.
Registration/renewal prices are to low even for long names.
They should be at least 0.1 NMC = 0.1 USD.

the registration needs to be less imo... maybe name_update should cost (i think it does if you update before a certain time period?), although maybe settxfee overrides it??

if names cost 0.1nmc.. this is only a total of a possible 210million names to cover domains, names, logins, usernames or whatever other things we use it for in the future (this is not including names already bought, some for 50 etc etc)...
need some way of releasing the locked fee names.. or the names have to be very low cost so billions of names can be created..
ultimately new names should be free or almost free.. but then it really could be spammed.. I think it should keep going down in price as intended.
hero member
Activity: 504
Merit: 500

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


This is correct. I agree.
Registration/renewal prices are to low even for long names.
They should be at least 0.1 NMC = 0.1 USD.
member
Activity: 112
Merit: 10

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

legendary
Activity: 1708
Merit: 1020
Hmm, what is the point of 1. and 2. if they get overwritten in 3. ?   IMHO 3. to 5. would be enough.
I forgot a '+' in 3.
Smiley

Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).
There is an additional rule at the end of the fee function to require more and more fees is block has reached 50% of its size. So, more fees, more chances to be in the next block in case of flood.
Interesting... I guess Bitcoin has that, too. So it is even cheaper to bully normal txs out of a block.
(https://bitcointalksearch.org/topic/can-anybody-stall-bitcoin-for-72btc-per-hour-answer-no-148211)

? I thought txIns would decrease the fee?
I first proposed that but there are 3 problems :
- each txIn is where the signature will be verified, and it costs CPU
- if you have 50 txIn and 50 txOut, you'll pay 0 (50-50) additional fee on this part
- you can send 1000 tx to yourself for "free" (1000 small tx) and then consolidate to yourself (1000 txIn 1 txOut) for "free"

So, here is what can be done for txOut/txIn :
fee += (nb txOut - 2) * baseFee + (nb txIn - 2 * baseFee / 2)
Sounds good.

Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of  selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.

Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.
So, we need to enforce the 0.01NMC (or wathever value we chose) of name_new. And forget the fees based on the size of the name...
I would not mind  Roll Eyes

[...]
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.
Not if the name is expired (he may not spoke about that case). Not sure it would be a good idea.
Hmm, it makes reregistering cheaper which is bad. Other problems?


Block size limit
It should be checked that the block size limit of the new version is the same as in the old version. Pre fork height that is.
https://bitcointalksearch.org/topic/alert-chain-fork-caused-by-pre-08-clients-dealing-badly-with-large-blocks-152030   


legendary
Activity: 2912
Merit: 1060
Namecoin could have done well if stupid Opendns cared about the community like they used to and resolved .bit
But the dipshits dont care about opendns or dnsomatic any more and only trying to make cash from "Umbrella"
Pages:
Jump to: