[ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65%

[danbi]

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?

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.

[1714928914]

1714928914

[1714928914]

1714928914

[1714928914]

1714928914

[cryptonit]

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

[pallas]

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 ;-)

[cryptonit]

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

[pallas]

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?

[danbi]

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?

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

[polanskiman]

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?

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.

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?

[polanskiman]

still it would be interesting to know why u fail more than others
it could be afaik u not from europe or usa that u have not much fast responding nodes near u
and u have timing issues get ur minting confirmed before someone else successful minted?

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:

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

Yes on a Mac Pro - 8 cores. Wallet 2.0.3

Latency seems indeed high with recommended node (193.68.21.19):

Code:

PING 193.68.21.19 (193.68.21.19): 56 data bytes
64 bytes from 193.68.21.19: icmp_seq=0 ttl=48 time=288.511 ms
64 bytes from 193.68.21.19: icmp_seq=1 ttl=49 time=286.108 ms
64 bytes from 193.68.21.19: icmp_seq=2 ttl=48 time=286.064 ms
64 bytes from 193.68.21.19: icmp_seq=3 ttl=48 time=286.237 ms
64 bytes from 193.68.21.19: icmp_seq=4 ttl=49 time=285.977 ms
64 bytes from 193.68.21.19: icmp_seq=5 ttl=50 time=286.908 ms
64 bytes from 193.68.21.19: icmp_seq=6 ttl=49 time=285.876 ms
64 bytes from 193.68.21.19: icmp_seq=7 ttl=48 time=286.490 ms
64 bytes from 193.68.21.19: icmp_seq=8 ttl=49 time=286.652 ms
64 bytes from 193.68.21.19: icmp_seq=9 ttl=49 time=286.026 ms
64 bytes from 193.68.21.19: icmp_seq=10 ttl=49 time=286.078 ms

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?

[alt-fan]

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!

[danbi]

Latency seems indeed high with recommended node (193.68.21.19):

Code:

PING 193.68.21.19 (193.68.21.19): 56 data bytes
64 bytes from 193.68.21.19: icmp_seq=0 ttl=48 time=288.511 ms
64 bytes from 193.68.21.19: icmp_seq=1 ttl=49 time=286.108 ms
64 bytes from 193.68.21.19: icmp_seq=2 ttl=48 time=286.064 ms
64 bytes from 193.68.21.19: icmp_seq=3 ttl=48 time=286.237 ms
64 bytes from 193.68.21.19: icmp_seq=4 ttl=49 time=285.977 ms
64 bytes from 193.68.21.19: icmp_seq=5 ttl=50 time=286.908 ms
64 bytes from 193.68.21.19: icmp_seq=6 ttl=49 time=285.876 ms
64 bytes from 193.68.21.19: icmp_seq=7 ttl=48 time=286.490 ms
64 bytes from 193.68.21.19: icmp_seq=8 ttl=49 time=286.652 ms
64 bytes from 193.68.21.19: icmp_seq=9 ttl=49 time=286.026 ms
64 bytes from 193.68.21.19: icmp_seq=10 ttl=49 time=286.078 ms

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?

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.

[danbi]

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!

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.

[cryptonit]

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?

60ms

[cryptonit]

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!

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

[pallas]

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!

[alt-fan]

@danbi and @cryptonit: thanks!

Everything worked like a charm: in less than 30 minutes, I downloaded wallet and blockchain, and accessed my old DMD balance. However, I can't withdraw from cryptsy (it says their wallet is offline, updating to the new version...).

Two questions:
a) Must I leave the wallet open at all times to earn PoS? What if I encrypt/lock it? Will PoS still be active?
b) when launching the wallet, it takes ages to connect to the first nodes in the network. anything I can do to speed this up?

[pokeytex]

Woo Hoo!  I got my DMD's in my wallet today!  It took a couple phone calls to them but they finally pulled through.  Once I had them on the phone they quickly figured out what happened.  I am a happy camper again!  I am going to test some more small purchases on Cryptsy and send to my wallet to see how it goes.  I did inform the gentleman I spoke with that we are now on 2.0.3.  He was not aware of the new wallet.

Pokeytex

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

HR
I sent you a PM did you get it?
Poke

[HR]

HR
I sent you a PM did you get it?
Poke

I was reading around and came across this, and, the answer now is, YES!

The PM notifications just don't seem to get my attention. lol

Thanks again for the info. I'm sure it will help.

[cryptonit]

@danbi and @cryptonit: thanks!

Everything worked like a charm: in less than 30 minutes, I downloaded wallet and blockchain, and accessed my old DMD balance. However, I can't withdraw from cryptsy (it says their wallet is offline, updating to the new version...).

Two questions:
a) Must I leave the wallet open at all times to earn PoS? What if I encrypt/lock it? Will PoS still be active?
b) when launching the wallet, it takes ages to connect to the first nodes in the network. anything I can do to speed this up?

u have a diamond.conf file in diamond appdata folder as suggested on first page of this ANN?

listen=1
server=1
rpcuser=USER_NAME
rpcpassword=SOME_PASSWORD
rpcport=17772
addnode=193.68.21.19

also delete old peers.dat

regarding cryptsy we got used to their maintainaces take ages
we didnt tell them to upgrade wasnt a mandatory wallet release

[cryptonit]

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 #143 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 #142 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

[polanskiman]

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.

I have tested well over 20 IPs. They all give me similar lag. 

Having other nodes in Thailand wont serve me in any way as they will have the same problem.

There would need to be some node in Singapore since that's where most of Thai's IPS connects to the backbone. Japan would also be a good place.