Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 758. (Read 1260636 times)

use the old wallet.dat with new wallet
and transfer the dmd from cryptsy to ur old wallet adress
ur address didnt change

welcome back alt-fan at the bright side of life

60ms

Make sure you always keep copy of your original wallet. Also keep copies after you spend coins and after you mint -- the change left from the transfer goes to a new address in your wallet, unless you use coin control to send it to a specific already existing one. PoS has the capability to create new addresses too, although this is rare.

You should not expect any problems. It is also possible to download the pre-built block chain (look at the first post for links) to speed up syncing. But if you do it the traditional way, keep in mind the syncing is likely to stop at the switch point -- you need to stop and start the wallet again for it to continue past hat point. A well known artifact from the switch time, which we work on.

We went to great lengths to ensure old wallets/coins are well preserved. If you run into any troubles, please share the details.

Well, it's on my (country-wide) network, so

PING 193.68.21.19 (193.68.21.19): 56 data bytes
64 bytes from 193.68.21.19: icmp_seq=0 ttl=60 time=9.308 ms
64 bytes from 193.68.21.19: icmp_seq=1 ttl=60 time=9.201 ms
64 bytes from 193.68.21.19: icmp_seq=2 ttl=60 time=8.969 ms
64 bytes from 193.68.21.19: icmp_seq=3 ttl=60 time=9.484 ms
64 bytes from 193.68.21.19: icmp_seq=4 ttl=60 time=9.747 ms
64 bytes from 193.68.21.19: icmp_seq=5 ttl=60 time=9.265 ms
64 bytes from 193.68.21.19: icmp_seq=6 ttl=60 time=9.029 ms
64 bytes from 193.68.21.19: icmp_seq=7 ttl=60 time=9.412 ms
64 bytes from 193.68.21.19: icmp_seq=8 ttl=60 time=9.563 ms
64 bytes from 193.68.21.19: icmp_seq=9 ttl=60 time=9.200 ms

--- 193.68.21.19 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.969/9.318/9.747/0.227 ms

From the node to north-west Europe (Amsterdam)

PING ns.ripe.net (193.0.9.6): 56 data bytes
64 bytes from 193.0.9.6: icmp_seq=0 ttl=59 time=41.126 ms
64 bytes from 193.0.9.6: icmp_seq=1 ttl=59 time=41.023 ms
64 bytes from 193.0.9.6: icmp_seq=2 ttl=59 time=40.963 ms
64 bytes from 193.0.9.6: icmp_seq=3 ttl=59 time=40.903 ms
64 bytes from 193.0.9.6: icmp_seq=4 ttl=59 time=41.125 ms
64 bytes from 193.0.9.6: icmp_seq=5 ttl=59 time=40.897 ms
64 bytes from 193.0.9.6: icmp_seq=6 ttl=59 time=41.208 ms
64 bytes from 193.0.9.6: icmp_seq=7 ttl=59 time=41.025 ms
64 bytes from 193.0.9.6: icmp_seq=8 ttl=59 time=41.015 ms
64 bytes from 193.0.9.6: icmp_seq=9 ttl=59 time=41.155 ms

--- ns.ripe.net ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 40.897/41.044/41.208/0.101 ms

(Frankfurt is less)

From the node to US East Coast:

PING svnmir.nyi.freebsd.org (96.47.72.118): 56 data bytes
64 bytes from 96.47.72.118: icmp_seq=0 ttl=44 time=111.453 ms
64 bytes from 96.47.72.118: icmp_seq=1 ttl=44 time=111.126 ms
64 bytes from 96.47.72.118: icmp_seq=2 ttl=44 time=111.160 ms
64 bytes from 96.47.72.118: icmp_seq=3 ttl=44 time=111.444 ms
64 bytes from 96.47.72.118: icmp_seq=4 ttl=44 time=111.070 ms
64 bytes from 96.47.72.118: icmp_seq=5 ttl=44 time=111.051 ms
64 bytes from 96.47.72.118: icmp_seq=6 ttl=44 time=111.203 ms
64 bytes from 96.47.72.118: icmp_seq=7 ttl=44 time=111.125 ms
64 bytes from 96.47.72.118: icmp_seq=8 ttl=44 time=111.050 ms
64 bytes from 96.47.72.118: icmp_seq=9 ttl=44 time=111.233 ms

--- svnmir.nyi.freebsd.org ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 111.050/111.191/111.453/0.141 ms

From the node to the US West Coast:

PING svnmir.ysv.freebsd.org (8.8.178.107): 56 data bytes
64 bytes from 8.8.178.107: icmp_seq=0 ttl=42 time=188.895 ms
64 bytes from 8.8.178.107: icmp_seq=1 ttl=42 time=189.371 ms
64 bytes from 8.8.178.107: icmp_seq=2 ttl=42 time=189.402 ms
64 bytes from 8.8.178.107: icmp_seq=3 ttl=42 time=188.861 ms
64 bytes from 8.8.178.107: icmp_seq=4 ttl=42 time=189.056 ms
64 bytes from 8.8.178.107: icmp_seq=5 ttl=42 time=189.369 ms
64 bytes from 8.8.178.107: icmp_seq=6 ttl=42 time=189.098 ms
64 bytes from 8.8.178.107: icmp_seq=7 ttl=42 time=188.529 ms
64 bytes from 8.8.178.107: icmp_seq=8 ttl=42 time=188.519 ms
64 bytes from 8.8.178.107: icmp_seq=9 ttl=42 time=188.618 ms

--- svnmir.ysv.freebsd.org ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 188.519/188.972/189.402/0.327 ms


It is clear you need more nodes close by. Perhaps investigate the network topology and see where another more or less permanent node cane placed.

Hi everyone,

I've been away from the crypto world for the last few months. I'm glad to see the great progress the DMD community has made all this time.

Here's my (newbie) question: I have quite a few DMD at an old wallet (before switching to the new algorithm) and a few more at Cryptsy. Can I transfer them to the new wallet? How? Is it just replacing wallet.dat in the new wallet installation and withdrawing the 'old' DMD from Cryptsy to a new wallet address?

I've just downloaded the new wallet and I'm waiting for it to sync, but I'm asking before I made any stupid move and risk losing the coins!

Thanks!

Yes on a Mac Pro - 8 cores. Wallet 2.0.3

Latency seems indeed high with recommended node (193.68.21.19):


I've tested all peers currently connected to my wallet. All the IPs that responded have a response time over 280ms.

What do you guys get?

Noted. So basically being in the third world, on a MAC, far form everyone dooms me! Yes that node is the only one that I have added to the .conf file.

I think it's fine that the wallet logs these failed attempts. What I did is simply export the transactions into a .csv file then filtered it.

How would you go on and make the wallet hash more without any external hasher?

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

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?

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

Not much coins indeed. But if I lock the wallet cpu usage drops drammatically: POS is to blame ;-)

Vote for Diamond DMD on

click pic or this link https://www.mintpal.com/voting#DMD

dont spend BTC for voting! (better spend btc to buy more dmd   )
create a mintpal account deposite some little btc amount buy some other coins
(or deposit and sell some other coins which are traded at mintpal)
after that u able to vote each hour for free
once u did one trade on mintpal u allowed to vote each hour without need to pay


place #146 now

i set a bounty from my own wallet (not foundation)

paying 1 DMD to everyone who reached a new rank

so first one reporting #145 and walletaddress
@ http://bit.diamonds/community/index.php/topic,16.0.html
gets 1 DMD by me (or alex if he faster and ninja rewarding again)

IMPORTANT only claim rewards on
http://bit.diamonds/community/index.php/topic,16.0.html

No.

Minting is a random process. You mint a block, then post it to the network (block chain) and see if you were first. If the block is accepted in the block chain, you add the earnings to your wallet. If not, you lose nothing. As if you never minted. It is exactly like orphans on the network.

The reasons we see more PoS orphans than PoW orphans is.. as expected, because of the low PoS difficulty. We would see about the same amount of PoW orphans if we had such low PoW difficulty and the same number of miners. In order for PoS difficulty to rise, more people should open their wallets for minting. You won't mint more often, but the percentage of failed attempts will be much lower.
This is essentially what can be done.

Contrary to PoW, where you compete based on your hash power, with PoS you compete based on your (individual amount's) coin age (the multiplication of coin amount with the age of when they arrived in your wallet). You waste more or less the same hash power (the wallet hashes sha256 for PoS) as you would with or without successful stake. The hashing exists in order to provide for randomness, or luck, it is very low-rate.

In theory, this could be fixed: have your wallet do massive hashing, even connect an external sha256 hasher, or few -- and the result you will receive is only almost guaranteed lack of orphans, you will not stake more or more frequently.

Having said all this, yes, it's disturbing to look at these things in the logs. Perhaps the logging routines might be redesigned to only log successful stakes, but.. that changes the purpose of the log, which is to provide you aid in diagnosing what and why happens.

PS: Yes, and the latency also plays a role. Try to have connection to well connected nodes. At the moment, 193.68.21.19 is one such node.

as i said around 1% of minting attempts have to try a second time all other successful first attempt
we both use wallet 2.0.3 i am on windows u are on mac?
then we need to get feedback from someone on mac too if he have a poor minting success rate too

if not compare the latency of the peers that are connected to you

im my first tough would be true and u have high latency to your peers there is nothing we from diamond team can do to fix it

promote dmd in ur area try get some peers running with good latency for u and add them to ur addnode list

as we learn from mining latency is a factor
and its also a factor in minting
ur minting attempt is only successful if he is proagated fast enough in the network

I am not worried about the cosmetic issue, but more about the the fact that most of my minting attempts are unsuccessful.

If the issue is a timing issue isn't there something you guys could do to limit this?

Here is a list of my minting attempts; Only 8 where successful to this day out of 39 attempts:

The user interface (MPOS) of http://dmdpool.digsys.bg has been updated to the latest stable version. The new version has a small button on the dashboard (down below) to turn off sound. Enjoy!

Please report any issues you may have.

Pokeytex, I'm still trying to get mine (they send me a periodic/idiotic e-mail saying they appreciate my patience, etc., but do nothing, and that after having told me over 6 weeks ago that a re-send had been approved); what phone number did you use, and who did you speak with?

PM me if you want to keep this below radar.

TIA

-------------------------------
answer from them:

Hello,


I passed this information on to the tech that confirms hash rates.  That said, this is wonderful information you have provided us and I was wondering if you can point us to a forum post that we would monitor for future reference.


Thanks!


Ted
CoinWarz Support


---------------------------------

@ coinwarz team

thx that u fast respond to user feedback!
but as u know do such tests on regulary base is very time consuming
u have to scan market for mining hardware driver and mining software permanently to keep it accurate

my time is bound for diamond foundation tasks i cant offering repeat this tests regulary
but  if we dedect again groestl algo rating is way underrated we will tell ya again

br cryptonit


(the numbers on coinwarz default hashrating for compare algo hasher each 1000€ mining gear are still wrong i expect them to run own tests on all algos not only the 3 that are  included in my short tests. basical i understand their aim of new default hashrating as a atempt to defend scrypt and promote scrypte asic mining gear.........)

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?

seen at cryptsy seems they care and update to 2.0.3 now
without us even asking them (because not mandatory)