thanks for the answer.
a couple questions:
should cpu usage go down when coinage of my coins is over?
the cpu of my nas is very weak (currently at 70% usage): if I get more coins in the future, will I risk not being able to mint any longer?
If I remember right, the compiler you used is an older one (gcc 4.2.1?) -- this means much less optimizations and you might have resorted to -O0 to make it run. Compiler optimizations make very big difference. The wallet tries to pace down the PoS hashing, but it still has to do calculations. When you have more eligible coins, it wastes more CPU. When you have more addresses within the wallet, it wastes more CPU. Therefore, when you mint your coins, for a period of time you will have lower CPU usage. Look at compiler optimizations first  I used to compile it with the default setting of -O2. Just tried with -O3 but I don't see any difference. Maybe I should compile a newer gcc but it will take ages! |
|
|
|
Not much coins indeed. But if I lock the wallet cpu usage drops drammatically: POS is to blame ;-)
thats normal POS behavior part of POS attempts is "hashing" (a simple version of it but still done by cpu and create cpu useage) who is able mint the next block is same as in mining a competition the only difference is that its can be only donewith wallet included miner and that the hashing power (or lets say chance to successful mint a block) is also moddified with the coin weight the reward when u successful mint is then determined by the coin-age once u won the minting competition thanks for the answer. a couple questions: should cpu usage go down when coinage of my coins is over? the cpu of my nas is very weak (currently at 70% usage): if I get more coins in the future, will I risk not being able to mint any longer? |
|
|
|
paper wallet looks good! :-)
on a side note, the new wallet uses more cpu than the previous one.
maybe it's because of the new indexing, danbi probably knows...
Another culprit might be coin control. Do you have that enabled? It should be disabled, however I don't know a way to check it on a headless client. An additional information which may be useful is that the load on the CPU is almost constant and about 30% higher with the new wallet. 30% is way too much. Haven't noticed such behavior myself.. There is no way to enable, or use coin control in the headless client at the moment. This is one deficiency of the current implementation. However, higher CPU utilization might be because you have more coins eligible for stake. What happens if you disable PoS? Not much coins indeed. But if I lock the wallet cpu usage drops drammatically: POS is to blame ;-) |
|
|
|
why is this not released for other pools? :s
because the working pool is his own and he wants to make money :-) |
|
|
|
paper wallet looks good! :-)
on a side note, the new wallet uses more cpu than the previous one.
maybe it's because of the new indexing, danbi probably knows...
Another culprit might be coin control. Do you have that enabled? It should be disabled, however I don't know a way to check it on a headless client. An additional information which may be useful is that the load on the CPU is almost constant and about 30% higher with the new wallet. |
|
|
|
|
paper wallet looks good! :-)
on a side note, the new wallet uses more cpu than the previous one.
maybe it's because of the new indexing, danbi probably knows...
|
|
|
|
|
First of all happy birthday diamond!
I'm running the new wallet on the qnap nas and it's all right.
The quick index is very welcome on such a slow device.
Danbi if you could add the "boost::" in front of random() in main.cpp I'd avoid stashing on every git pull.
Thanks diamond people for the continued support, updates and care! :-)
|
|
|
|
i stop pay for voting MINTPAL the new announcement they made leave to less time for us achieve it  1st september isnt reachable to be top of list it would need some more weeks/months and mintpal stop adding coins based on voting list at 1 september mintpal page:
Important: Please be aware that we are phasing out the voting system. We have removed the option to make payment votes and will stop taking voting winners from 1st September onwards. The system will continue as normal until then. They still need a way to choose which coins to add. If they want to give a good service, they'll have to listen to the customers in some way. We'll make sure diamond has its chance. |
|
|
|
|
To get the speed you should use the optimised kernel, but it works with his own pool only.
|
|
|
|
since people can only vote once an hour, if two votes are needed to gain a position, I suppose people will wait for someone else to give that vote, so they can claim the bounty.
maybe I'm paranoid :-D
It's just a bunch of bit, this DMD. or a tiny bit in your electricity bill, or a tiny bit in your computer amortization etc. You guys waster a page here arguing about it. But then, if there are people at exchanges who look at the length of the discussion thread -- that is positive too. You can't go wrong both ways. Well this is marketing, which unfortunately seems to be the most important factor for coin success ;-) |
|
|
|
question: do I loose coinage when I move coins from one account to another, inside the same wallet, with the "move" command?
I would say yes, it does destroy it if it's a different address, it needs to be accounted somehow and the timestamp would be one of these things that change. Danbi needs to confirm or disprove that, however. When in doubt, look at the source The code says there are no block chain operations involved in moving within the wallet. Therefore, the normal answer would be "no". You can always test: 1. do listunspent, save the result 2. move coins 3. do listunspent again, compare with the previous result If no difference, you do not lose any coin age. The coin age (in blocks) is in confirmations: It is however possible, that a move destroys coin age if it moves to a new address - perhaps if the move involves splitting coins etc. The correct answer is: coin age is preserved as long as the coins remain at the same address, according to the block chain. Thanks Danbi for the extensive answer. I did the listunspent test, unfortunately a block and a transaction came in between the two commands so there are tons of differences :-D The address is indeed different: I believe that two accounts in the same wallet can't have the same address (but they can have more than one each). So I still do not understand: the address is different but there is no blockchain operations involved... UPDATE: I did the "listunspent" test again and I can confirm that the "move" command doesn't make a difference. I still don't understand how a coin can be moved between two addresses without notifying the blockchain (how will an online block explorer know?), but this is not DMD specific so I'll go and study some bitcoin ;-) |
|
|
|
|
since people can only vote once an hour, if two votes are needed to gain a position, I suppose people will wait for someone else to give that vote, so they can claim the bounty.
maybe I'm paranoid :-D
|
|
|
|
Gonna be costly for you with 184 to go I have been voting as often as I can remember to same for me. but, putting a bounty for gaining a position is not a good idea IMHO: when 2 votes are needed, everybody will wait. i easy spend that 184 DMD and i will add it to any maybe coming additional foundation bounties for voting its a private initiative from me i think u missinterpret the waiting game pallas...... i cant verify who voted...... i can only verify who reported and if the rank really is reached so no fear to vote just fear to report at thread not at first  I was just saying that I think this bounty will make DMD get less votes because people will wait for someone else to get to 1 vote less that the next position. |
|
|
|
Gonna be costly for you with 184 to go I have been voting as often as I can remember to same for me. but, putting a bounty for gaining a position is not a good idea IMHO: when 2 votes are needed, everybody will wait. |
|
|
|
I can't sync the wallet , which nodes should i use ?!
i have these settings right now:
listen=1
server=1
daemon=1
rpcuser=u
rpcpassword=p
rpcport=1441
addnode=groestlcoin.net
addnode=92.234.241.91
addnode=217.44.27.235
addnode=193.242.149.63
addnode=209.126.71.54
addnode=79.117.53.154
addnode=92.39.203.216
addnode=61.55.141.196
addnode=151.41.36.112
addnode=5.9.157.13
addnode=74.91.18.210
addnode=222.65.39.59
addnode=83.242.125.165
addnode=66.232.41.176
addnode=71.96.61.207
addnode=37.187.129.122
addnode=62.210.162.235
addnode=88.167.215.32
addnode=69.197.137.58
addnode=103.16.218.165
addnode=84.98.85.30
addnode=76.16.120.82
addnode=62.210.123.27
addnode=117.13.253.241
I had great benefit when enabling UPNP (assuming it's available on the router) or configuring incoming NAT. |
|
|
|
no, it will not work: you need support in the C code as well. |
|
|
|
|
10 set 1 hour stopwatch
20 refresh
30 vote
40 goto 10
|
|
|
|
question: do I loose coinage when I move coins from one account to another, inside the same wallet, with the "move" command?
I would say yes, it does destroy it if it's a different address, it needs to be accounted somehow and the timestamp would be one of these things that change. Danbi needs to confirm or disprove that, however. When in doubt, look at the source The code says there are no block chain operations involved in moving within the wallet. Therefore, the normal answer would be "no". You can always test: 1. do listunspent, save the result 2. move coins 3. do listunspent again, compare with the previous result If no difference, you do not lose any coin age. The coin age (in blocks) is in confirmations: It is however possible, that a move destroys coin age if it moves to a new address - perhaps if the move involves splitting coins etc. The correct answer is: coin age is preserved as long as the coins remain at the same address, according to the block chain. Thanks Danbi for the extensive answer. I did the listunspent test, unfortunately a block and a transaction came in between the two commands so there are tons of differences :-D The address is indeed different: I believe that two accounts in the same wallet can't have the same address (but they can have more than one each). So I still do not understand: the address is different but there is no blockchain operations involved... |
|
|
|
|
question: do I loose coinage when I move coins from one account to another, inside the same wallet, with the "move" command?
|
|
|
|
|
new algos is not the solution: asic are not available for X11 and similar but profitability is so low anyway.
the problem is people mining with free or very low price electricity (botnets, china which pays 0.08 per KH/H, etc.).
|
|
|
|
|
Show Posts
