[ANN] United SciFi Coin [SCIFI] PoW/PoS - page 7.

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

Quote from: Dunkelheit667 on April 26, 2018, 11:28:29 AM

Quote from: vampirus on April 26, 2018, 09:09:08 AM

May be change some other parameters, remove POW or change POS rate?

I'm not a coder by any means, but would it help to implement something like this:

Quote

Therefore, well behaving nodes should shelve future blocks until their block time is reached, so they won't participate in staking blocks on top of a future block. The clocks of well behaving nodes are not expected to drift more than a few seconds, meaning that an honest future block is not expected to be shelved longer than expected network relay times.

Source: https://github.com/peercoin/rfcs/blob/master/text/0001-exponential-pos-target-for-block-time-stabilization/0001-exponential-pos-target-for-block-time-stabilization.md

SCIFI have another method block time stabilization. In old Novacoin code (QBT, HYP) all was OK, but in new code they accidently create this bug.

Dunkelheit667

legendary

Activity: 1045

Merit: 1157

no degradation

Quote from: vampirus on April 26, 2018, 09:09:08 AM

May be change some other parameters, remove POW or change POS rate?

I'm not a coder by any means, but would it help to implement something like this:

Quote

Therefore, well behaving nodes should shelve future blocks until their block time is reached, so they won't participate in staking blocks on top of a future block. The clocks of well behaving nodes are not expected to drift more than a few seconds, meaning that an honest future block is not expected to be shelved longer than expected network relay times.

Source: https://github.com/peercoin/rfcs/blob/master/text/0001-exponential-pos-target-for-block-time-stabilization/0001-exponential-pos-target-for-block-time-stabilization.md

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

Quote from: Xantor1234 on April 26, 2018, 07:50:45 AM

Please fork / fix. Right now this can happen again at any moment and only you (as major POS owner) can cause (and fix) it, which is not a good thing for a coin.

If you put up a fixed version I'll immediately update it everywhere. My main node always has more than 30 connections to it so it'll help force the chain over.

Please make the new version compulsory after 1,000 blocks or so.

I check, it is not depend on POS power.
May be change some other parameters, remove POW or change POS rate?

Xantor1234

newbie

Activity: 17

Merit: 0

Ignoring the half Chinese nonsense bot posts,

Please fork / fix. Right now this can happen again at any moment and only you (as major POS owner) can cause (and fix) it, which is not a good thing for a coin.

If you put up a fixed version I'll immediately update it everywhere. My main node always has more than 30 connections to it so it'll help force the chain over.

Please make the new version compulsory after 1,000 blocks or so.

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

I simulate this event again and found bug in latest Novacoin code:
Future drift checks only for PoW blocks Sad

Need hardfork to fix it.

Christini

member

Activity: 209

Merit: 10

i have study your project n hope that will rise surely
merculet

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

Quote from: sunk818 on April 25, 2018, 12:31:05 PM

Quote from: vampirus on April 25, 2018, 12:24:14 PM

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?

Quote from: vampirus on April 25, 2018, 12:24:14 PM

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.

sunk818

full member

Activity: 1176

Merit: 111

Quote from: vampirus on April 25, 2018, 12:24:14 PM

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?

Quote from: vampirus on April 25, 2018, 12:24:14 PM

Checkpoint server was also off.

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

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

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

full member

Activity: 1176

Merit: 111

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.

MikeRG2880

newbie

Activity: 13

Merit: 0

Quote from: dnp on April 24, 2018, 10:07:58 PM

Quote from: sunk818 on April 24, 2018, 06:40:21 PM

Quote from: vampirus on April 24, 2018, 02:34:18 PM

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

Xantor1234

newbie

Activity: 17

Merit: 0

Nice centralized coin you have there.

This needs to be fixed asap otherwise no use continuing.

dnp

full member

Activity: 401

Merit: 110

Quote from: sunk818 on April 24, 2018, 06:40:21 PM

Quote from: vampirus on April 24, 2018, 02:34:18 PM

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

sunk818

full member

Activity: 1176

Merit: 111

Quote from: Dunkelheit667 on April 24, 2018, 05:14:23 PM

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.

sunk818

full member

Activity: 1176

Merit: 111

Quote from: vampirus on April 24, 2018, 02:34:18 PM

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?

Dunkelheit667

legendary

Activity: 1045

Merit: 1157

no degradation

Quote from: vampirus on April 24, 2018, 02:34:18 PM

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.

vampirus

hero member

Activity: 982

Merit: 520

Nature decays, but Latinum lasts forever. RoA:102

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

legendary

Activity: 1045

Merit: 1157

no degradation

Quote from: MikeRG2880 on April 24, 2018, 08:10:57 AM

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...

Quote from: Xantor1234 on April 24, 2018, 10:49:24 AM

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. Undecided

Xantor1234

newbie

Activity: 17

Merit: 0

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

MikeRG2880

newbie

Activity: 13

Merit: 0

Quote from: Dunkelheit667 on April 23, 2018, 12:11:20 PM

Quote from: dnp on April 23, 2018, 12:06:22 PM

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.

Topic: [ANN] United SciFi Coin [SCIFI] PoW/PoS - page 7. (Read 42089 times)