So a getblock 00000000015a9f916d9100e652b18d562e0300a2ad97bf5245171afb16e7e9e7
should return 471058
Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 775. (Read 1260636 times)
July 02, 2014, 03:09:49 AM
July 02, 2014, 03:06:46 AM
Exactly I thought checkpointing was done rather infrequently ... 2.0.2.1 the checkpoint remained same for long periods of time. So If I want to get a check on chain validity use getblock (whatever last block I see in getcheckpoint) and have someone verify the getblock?
July 02, 2014, 02:52:27 AM
Come on people. These checkpoints are good thing. :-)
Diamond does real-time checkpointing, in order to prevent the block chain from forking (faster) than otherwise. Each and every block is check pointed (in theory).
Unfortunately, at the time of the fork the checkpointing machinery did not function, thus contributing to the amplitude of the mess we saw.
Therefore, in general, with Diamond you can be sure you are on the right block chain if you see recent checkpoints. If your checkpoints are too old, you should be worried (that no checkpoints are happening and this must be fixed) or, you are disconnected from the main chain.
Diamond can work perfectly without the real-time checkpointing, just as you saw for some days, but you know what happens then...
It is safe to mint at any time. You may, or may not mint successfully -- it's pretty much random process. There is no easy way to lose your coin age, except by sending the coins to a new address.
Diamond does real-time checkpointing, in order to prevent the block chain from forking (faster) than otherwise. Each and every block is check pointed (in theory).
Unfortunately, at the time of the fork the checkpointing machinery did not function, thus contributing to the amplitude of the mess we saw.
Therefore, in general, with Diamond you can be sure you are on the right block chain if you see recent checkpoints. If your checkpoints are too old, you should be worried (that no checkpoints are happening and this must be fixed) or, you are disconnected from the main chain.
Diamond can work perfectly without the real-time checkpointing, just as you saw for some days, but you know what happens then...
It is safe to mint at any time. You may, or may not mint successfully -- it's pretty much random process. There is no easy way to lose your coin age, except by sending the coins to a new address.
Agreed. There was a misconception that checkpoint should remain the same thus the question from uthajohn.
All good in the hood!
July 02, 2014, 02:49:08 AM
Come on people. These checkpoints are good thing. :-)
Diamond does real-time checkpointing, in order to prevent the block chain from forking (faster) than otherwise. Each and every block is check pointed (in theory).
Unfortunately, at the time of the fork the checkpointing machinery did not function, thus contributing to the amplitude of the mess we saw.
Therefore, in general, with Diamond you can be sure you are on the right block chain if you see recent checkpoints. If your checkpoints are too old, you should be worried (that no checkpoints are happening and this must be fixed) or, you are disconnected from the main chain.
Diamond can work perfectly without the real-time checkpointing, just as you saw for some days, but you know what happens then...
It is safe to mint at any time. You may, or may not mint successfully -- it's pretty much random process. There is no easy way to lose your coin age, except by sending the coins to a new address.
Diamond does real-time checkpointing, in order to prevent the block chain from forking (faster) than otherwise. Each and every block is check pointed (in theory).
Unfortunately, at the time of the fork the checkpointing machinery did not function, thus contributing to the amplitude of the mess we saw.
Therefore, in general, with Diamond you can be sure you are on the right block chain if you see recent checkpoints. If your checkpoints are too old, you should be worried (that no checkpoints are happening and this must be fixed) or, you are disconnected from the main chain.
Diamond can work perfectly without the real-time checkpointing, just as you saw for some days, but you know what happens then...
It is safe to mint at any time. You may, or may not mint successfully -- it's pretty much random process. There is no easy way to lose your coin age, except by sending the coins to a new address.
July 02, 2014, 02:47:36 AM
OK thanks I get same result, will start minting again 
July 02, 2014, 02:40:07 AM
I'll wait until Danbi addresses the checkpoint timestamp updating too fast issue. I do not want to mint without being absolutely sure I am on right chain (started from the 20140701 database on OP). Wallet locked for the moment ...
Not sure what the problem is, ghetcheckpoint would show you the info on the current block and hash, if you use the command one minute later you will get a different result.
See this command which block number height it shows: getblock 00000000027872314919ee47efbd99e71625319f1377e5ad925654554414eab1
If it's 470703 than it's correct.
July 02, 2014, 02:19:50 AM
Noticed 10 Minted coins today again appearing with questions marks. I beleive orphaned again? Totalling ~30 minted coins to this day unavailable.
u lose nothing at orphaned minting atempt
the coin-age is given back to ur coins as soon as the atempt is a orphan and the stake ammount switches back to normal balance
i agree its a cosmetic problem unsuccessful atemps are visible in transaction log
one posible reson for orphan minting atempts is unlock wallet while its not full synced
if by some mirace reason u wana run ur wallet without a password then add
reservebalance=999999
to ur conf
and once wallet synced uturn on pos by use this command in console
reservebalance false
Thanks for the explanation.
Strangely those ~10DMD missing minted correspond to the 10DMD I didn't get yesterday from cryptohunger pool. Between 6am and 12am I didn't received any payment when in fact payments are normally processed hourly.
The previous failed minting attemps that took place on 26 June follow the same logic. No payment from pool, then failed minted coins corresponding to the mount that should have been paid.
July 02, 2014, 01:37:41 AM
Noticed 10 Minted coins today again appearing with questions marks. I beleive orphaned again? Totalling ~30 minted coins to this day unavailable.
u lose nothing at orphaned minting atempt
the coin-age is given back to ur coins as soon as the atempt is a orphan and the stake ammount switches back to normal balance
i agree its a cosmetic problem unsuccessful atemps are visible in transaction log
one posible reson for orphan minting atempts is unlock wallet while its not full synced
if by some mirace reason u wana run ur wallet without a password then add
reservebalance=999999
to ur conf
and once wallet synced uturn on pos by use this command in console
reservebalance false
July 02, 2014, 01:33:05 AM
cryptsy withdraws working again
can someone test deposit
regarding checkpoint in my opinion its working as it should
but danbi will find some words to explain it
can someone test deposit
regarding checkpoint in my opinion its working as it should
but danbi will find some words to explain it
July 01, 2014, 11:32:54 PM
Noticed 10 Minted coins today again appearing with questions marks. I beleive orphaned again? Totalling ~30 minted coins to this day unavailable.
July 01, 2014, 10:56:07 PM
hello i have a problem, unfortunately I can not connect to my rig to the pool dmdpool.digsys.bg:3345 and I can not get no reward as I do
try grs-sgminer from:
https://bitcointalksearch.org/topic/anngroestlmyriadgroestl-pool-closed-652849
https://github.com/srcxxx/grs-sgminer/releases/download/1.2.5/grs-sgminer1_2_5.zip
sample .conf:
"pools" : [
{
"url" : "stratum+tcp://dmdpool.digsys.bg:3333",
"user" : "user.dmd",
"normal-hashing" : "true",
"pass" : "x",
"poolname" : "dmdDanbi"
}
],
"kernel" : "groestlcoin",
Would a conf like this allow you to use that miner for groestl and diamond simply by changing your pool? Since they both use groestl, but only one uses normal-hashing true?
yes, i believe so. i havent tried it though, just omit normal-hashing true for none DMD pools
July 01, 2014, 10:08:51 PM
I'll wait until Danbi addresses the checkpoint timestamp updating too fast issue. I do not want to mint without being absolutely sure I am on right chain (started from the 20140701 database on OP). Wallet locked for the moment ...
You've got me a bit worried now that I am on the wrong one. I also used the blockchain from 20140701.
July 01, 2014, 10:02:42 PM
I'll wait until Danbi addresses the checkpoint timestamp updating too fast issue. I do not want to mint without being absolutely sure I am on right chain (started from the 20140701 database on OP). Wallet locked for the moment ...
July 01, 2014, 09:56:28 PM
hello i have a problem, unfortunately I can not connect to my rig to the pool dmdpool.digsys.bg:3345 and I can not get no reward as I do
try grs-sgminer from:
https://bitcointalksearch.org/topic/anngroestlmyriadgroestl-pool-closed-652849
https://github.com/srcxxx/grs-sgminer/releases/download/1.2.5/grs-sgminer1_2_5.zip
sample .conf:
"pools" : [
{
"url" : "stratum+tcp://dmdpool.digsys.bg:3333",
"user" : "user.dmd",
"normal-hashing" : "true",
"pass" : "x",
"poolname" : "dmdDanbi"
}
],
"kernel" : "groestlcoin",
Would a conf like this allow you to use that miner for groestl and diamond simply by changing your pool? Since they both use groestl, but only one uses normal-hashing true?
July 01, 2014, 09:54:40 PM
Almost positive im on the right chain and my
getcheckpoint shows

{
"synccheckpoint" : "000000000152c1d7ac3f5bf1d0eb7b955b6962bba652551c9a8ed69473f69702",
"height" : 470752,
"timestamp" : "2014-07-02 02:49:51 UTC"
}
Hope that helps you out a bit.
I am currently invested in HBN CAPS and DMD. All stake-able coins, for some reason I thought dmd was 2% stake. LOL to that, thanks for the heads up I guess I should read!
Current money supply around 484k... 1 mil to go! I think I will stake for a bit
getcheckpoint shows

{
"synccheckpoint" : "000000000152c1d7ac3f5bf1d0eb7b955b6962bba652551c9a8ed69473f69702",
"height" : 470752,
"timestamp" : "2014-07-02 02:49:51 UTC"
}
Hope that helps you out a bit.
I am currently invested in HBN CAPS and DMD. All stake-able coins, for some reason I thought dmd was 2% stake. LOL to that, thanks for the heads up I guess I should read!
Current money supply around 484k... 1 mil to go! I think I will stake for a bit
July 01, 2014, 09:15:52 PM
@Danbi
Seems to be a problem with checkpointing, It's updating faster than we can get a matching timestamp
Seems to be a problem with checkpointing, It's updating faster than we can get a matching timestamp
I had the same checkpoint info.....
{
"synccheckpoint" : "0000000002bbfd2c9b920ea43eaa5bd5a4adcfeb11600ca96f650b53b1ad6f56",
"height" : 470708,
"timestamp" : "2014-07-02 02:06:21 UTC"
}
So it look that we are on the same page at least.....
July 01, 2014, 09:10:29 PM
@Danbi
Seems to be a problem with checkpointing, It's updating faster than we can get a matching timestamp
Closing wallet for now I don't want to mint on a fork ...
Seems to be a problem with checkpointing, It's updating faster than we can get a matching timestamp
Closing wallet for now I don't want to mint on a fork ...
July 01, 2014, 09:06:13 PM
Looks like checkpoint updating WTF gonna be hard to see if I match
20:07:16

{
"synccheckpoint" : "0000000002bbfd2c9b920ea43eaa5bd5a4adcfeb11600ca96f650b53b1ad6f56",
"height" : 470708,
"timestamp" : "2014-07-02 02:06:21 UTC"
}
20:07:16

{
"synccheckpoint" : "0000000002bbfd2c9b920ea43eaa5bd5a4adcfeb11600ca96f650b53b1ad6f56",
"height" : 470708,
"timestamp" : "2014-07-02 02:06:21 UTC"
}
July 01, 2014, 09:04:43 PM
"synccheckpoint" : "000000000387eb64362c505bdea63808ce97e39c520a66e4184d359f13020ca3",
"height" : 470704,
"timestamp" : "2014-07-02 02:02:35 UTC"
}
"height" : 470704,
"timestamp" : "2014-07-02 02:02:35 UTC"
}
July 01, 2014, 08:42:30 PM
02:01:50

getcheckpoint
02:01:50

{
"synccheckpoint" : "000000000390100991ea4a9fd7e6d8e1c503821dc5ee96449049d9f1367b1703",
"height" : 469658,
"timestamp" : "2014-07-01 07:57:29 UTC"
}
loading my wallet now and will check if I get one dated 07-02 ...
getcheckpoint
02:01:50

{
"synccheckpoint" : "000000000390100991ea4a9fd7e6d8e1c503821dc5ee96449049d9f1367b1703",
"height" : 469658,
"timestamp" : "2014-07-01 07:57:29 UTC"
}

{
"synccheckpoint" : "00000000039ef4246d57c2fb273535be9409b2931d8ecdf9dad0aef6663e9323",
"height" : 470687,
"timestamp" : "2014-07-02 01:43:49 UTC"
}
Hmm differs from what I get
Do a getcheckpoint again this one is dated later ...Anyone else want to share what they are getting ?
20:02:48

{
"synccheckpoint" : "00000000027872314919ee47efbd99e71625319f1377e5ad925654554414eab1",
"height" : 470703,
"timestamp" : "2014-07-02 02:02:29 UTC"
}
Jump to: