[ANN] United SciFi Coin [SCIFI] PoW/PoS

[Xantor1234]

Something wrong with the chain?

LPool: Last share 29 hours ago
Solo: Everything rejected
Also haven't seen a POS hit for a day or so.

Please check?

[Dunkelheit667]

Something wrong with the chain?

LPool: Last share 29 hours ago
Solo: Everything rejected
Also haven't seen a POS hit for a day or so.

Please check?

https://lpool.name/explorer/SCIFI , http://cryptoguru.tk/Blocks/index.php?Currency=SCIFI , my node and wallet seem to be on the same high.

But yes, http://cryptoguru.tk/Charts/index.php?Currency=SCIFI shows there was no PoW block since yesterday and PoS seems to be slow, difficulty looks fine, odd. Can confirm I had my last stake 10h ago which is uncommon.

[MikeRG2880]

Something wrong with the chain?

LPool: Last share 29 hours ago
Solo: Everything rejected
Also haven't seen a POS hit for a day or so.

Please check?

Yeah noticed same thing here, no POW on pool or solo, and have had decent stake inputs but no rewards since height 181996.

[dnp]

Something wrong with the chain?

LPool: Last share 29 hours ago
Solo: Everything rejected
Also haven't seen a POS hit for a day or so.

Please check?

Yeah noticed same thing here, no POW on pool or solo, and have had decent stake inputs but no rewards since height 181996.

i'm noticing new blocks arriving timestamped 1 hour into the future the last couple days.
i turned off my daemon and going to wait a few days.

[Dunkelheit667]

i'm noticing new blocks arriving consistently 1 hour into the future the last couple days.

Just found this in my debug.log. Yes, seems to be an issue with timestamps:

Code:

CheckStake() : new proof-of-stake block found  
  hash: 782039806d45cb037e7b07e74ec1637058a8b5959b2d5d2fe348847a5a21b840 
proofhash: 0000014da281be708a96c9d89efb2c1707cb6bd7838eb97b8312cac76282e3fd  
target: 00000fa8ee0e0000000000000000000000000000000000000000000000000000
CBlock(hash=782039806d45cb037e7b07e74ec1637058a8b5959b2d5d2fe348847a5a21b840, ver=6, hashPrevBlock=74a4e46d294ce8880ab4f52e36a8239f55f5a28b9f3ad1b8439aa5f3de298bfd, hashMerkleRoot=ddc9251240bd996c2fca910c2992d73ad3fafe54012923bfd44a87079e616799, nTime=1524503117, nBits=1d00b1c6, nNonce=0, vtx=2, ...)
...
ERROR: AcceptBlock() : block's timestamp is too early
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: CheckStake() : ProcessBlock, block not accepted

Edit:
Yeah, guess there is something wrong with nTime/ntp.cpp? The following workaround 'fixed' my 'issue', but it's really... shady.

1) Close the UnitedSciFi client. Sync your system time.
2) Disable time syncing and set your local system time to current time + one hour.
3) Enable the NTP server on your local machine: https://www.interfacett.com/blogs/creating-standalone-ntp-server-windows/
4) Start the UnitedSciFi client.

PoS worked again.

[Xantor1234]

Not gonna mess with my system time. Closing deamons until good fix is found.

[MikeRG2880]

i'm noticing new blocks arriving consistently 1 hour into the future the last couple days.

Just found this in my debug.log. Yes, seems to be an issue with timestamps:

Code:

CheckStake() : new proof-of-stake block found  
  hash: 782039806d45cb037e7b07e74ec1637058a8b5959b2d5d2fe348847a5a21b840 
proofhash: 0000014da281be708a96c9d89efb2c1707cb6bd7838eb97b8312cac76282e3fd  
target: 00000fa8ee0e0000000000000000000000000000000000000000000000000000
CBlock(hash=782039806d45cb037e7b07e74ec1637058a8b5959b2d5d2fe348847a5a21b840, ver=6, hashPrevBlock=74a4e46d294ce8880ab4f52e36a8239f55f5a28b9f3ad1b8439aa5f3de298bfd, hashMerkleRoot=ddc9251240bd996c2fca910c2992d73ad3fafe54012923bfd44a87079e616799, nTime=1524503117, nBits=1d00b1c6, nNonce=0, vtx=2, ...)
...
ERROR: AcceptBlock() : block's timestamp is too early
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: CheckStake() : ProcessBlock, block not accepted

Edit:
Yeah, guess there is something wrong with nTime/ntp.cpp? The following workaround 'fixed' my 'issue', but it's really... shady.

1) Close the UnitedSciFi client. Sync your system time.
2) Disable time syncing and set your local system time to current time + one hour.
3) Enable the NTP server on your local machine: https://www.interfacett.com/blogs/creating-standalone-ntp-server-windows/
4) Start the UnitedSciFi client.

PoS worked again.

Curiosity question: to my untrained eye, won't the client fix also require forking/checkpoint from where the problem happened (181997?) since currently the UTC timestamps of all the blocks since then are wrong?  Trying to conceptualize how miners with the correct time could get back on the current longest chain without kludging the client to mess with how timestamps are agreed to.

[Xantor1234]

IMHO it _should_ fork as the blocks from that point are obviously wrong and only 'cheaters' profit.

[Dunkelheit667]

Curiosity question: to my untrained eye, won't the client fix also require forking/checkpoint from where the problem happened (181997?) since currently the UTC timestamps of all the blocks since then are wrong?  Trying to conceptualize how miners with the correct time could get back on the current longest chain without kludging the client to mess with how timestamps are agreed to.

Good question, don't know why some nodes seem to run 'one hour in the future' and nodes on the correct time accepted 'future' blocks. Guess to fix this without some kind of update, all nodes have to sync their time and disable PoS/PoW mining for one hour...

IMHO it _should_ fork as the blocks from that point are obviously wrong and only 'cheaters' profit.

Indeed, it should have forked, but did not.

[vampirus]

Something wrong was with time.windows.com server. I found that one of my computers set to 1 hour ahead since yesterday.
Just set computer time and restart wallet, soon all start working.

[Dunkelheit667]

Something wrong was with time.windows.com server. I found that one of my computers set to 1 hour ahead since yesterday.
Just set computer time and restart wallet, soon all start working.

PoS (with current time) and the pool seem to work again. Thanks for checking Grand Nagus.

[sunk818]

Something wrong was with time.windows.com server. I found that one of my computers set to 1 hour ahead since yesterday.
Just set computer time and restart wallet, soon all start working.

Hmm, I didn't see this on any of my computers. You said max time drift is 3 min, so wouldn't this limit prevent any times 1 hour into the future? Also, the time is UTC so even if time is ahead one hour, UTC time should still be correct regardless of what Windows tells you is the time.

Something buggy, no?

[sunk818]

PoS (with current time) and the pool seem to work again. Thanks for checking Grand Nagus.

lpool seems to be working about 2 hours ago. Block 183071 with difficult 3.501703. Then diff dropped to 2.1 9 blocks later.

[dnp]

Something wrong was with time.windows.com server. I found that one of my computers set to 1 hour ahead since yesterday.
Just set computer time and restart wallet, soon all start working.

Hmm, I didn't see this on any of my computers. You said max time drift is 3 min, so wouldn't this limit prevent any times 1 hour into the future? Also, the time is UTC so even if time is ahead one hour, UTC time should still be correct regardless of what Windows tells you is the time.

Something buggy, no?

it does seem dangerous that my (correct time) linux daemon/wallet was immediately accepting blocks generated 1 hour into the future. they should have been ignored (at least until the correct time catches up to the block's time.)

[Xantor1234]

Nice centralized coin you have there.

This needs to be fixed asap otherwise no use continuing.

[MikeRG2880]

Something wrong was with time.windows.com server. I found that one of my computers set to 1 hour ahead since yesterday.
Just set computer time and restart wallet, soon all start working.

Hmm, I didn't see this on any of my computers. You said max time drift is 3 min, so wouldn't this limit prevent any times 1 hour into the future? Also, the time is UTC so even if time is ahead one hour, UTC time should still be correct regardless of what Windows tells you is the time.

Something buggy, no?

it does seem dangerous that my (correct time) linux daemon/wallet was immediately accepting blocks generated 1 hour into the future. they should have been ignored (at least until the correct time catches up to the block's time.)

It would be interesting to see a postmortem from an expert like vamp.  Maybe too nuanced to be meaningful, but curious if it should be thought of as a low probability event that occurred (was it a specific case where majority high-stake pos miners with UTC+1 took over, but chain operation was still robust in the end), or actually a corner case because the fix required outright action from a majority miner (resetting their clock)?

Arguing against the latter point, was the "fix" simply that with enough miners coming online with the correct time it would "clean up" the network adjusted time (baseline https://en.bitcoin.it/wiki/Block_timestamp
)?

[sunk818]

I couldn't get solo mining working with bfgminer 5.4.2 on Windows, so I ended up using lpool.name. With the low difficulty, I imagine lpool.name has most of the network hash rate? If so, one snafu from their wallet could cause chain reaction issues? That pool is so under powered and slow to respond (server wise and admin wise), it does become a liability when the mining is not distributed.

[vampirus]

It was because I have too much PoS power and my chain win.
Checkpoint server was also off.
With more PoS miners and Checkpoint server online it never happen again.
In QBT on same computer all my blocks go orphan.

[sunk818]

It was because I have too much PoS power and my chain win.

I suppose dev has right to stake as well. If you want to turn it off on your wallet, you can do this via the .conf file right?

Checkpoint server was also off.

What does this mean? This is not default feature in UnitedSCIFI?

[vampirus]

It was because I have too much PoS power and my chain win.

I suppose dev has right to stake as well. If you want to turn it off on your wallet, you can do this via the .conf file right?

Checkpoint server was also off.

What does this mean? This is not default feature in UnitedSCIFI?

I stake only coins that receive as all other users. (KED, QBT, UFC, GPL, DPZ swap)
All unswapped coins out of stake.
Checkpoint server starts only on one computer with master key in config.
Currently SCIFI not on exchange and no need use checkpoint server.