Quote from: supasonic on July 03, 2015, 01:21:06 PM

Quote from: coolbeans94 on July 03, 2015, 03:44:26 AM

Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.

Just a suggestion a by no means a mandatory thing. The code would be about the client and its timing differences, not about the block chain. Most IBM PC variants lose about a second a day. Most OS'es adjust weekly for it and some applications adjust sooner. Ping times can be used to account for network latency on a node to node basis.

I'm still delving into the innards of the codebase to see how efficiently the protocol is being implemented locally but a drift not set low enough still leaves MintCoin open to attacks although the effects decrease the lower the drift. The information would be public and could become part of the protocol if it helps since we will be forking. I not aware of other coins that are implementing outside of the testnets.

If the consensus is 30 sec then it works. I myself am still reading up on the detail of this attack, a lot of details on POW coins and most of the POS stuff I'm reading is a little less. I like to see this discussion. Personally i think 30 seconds on a global network can cause issues, nothing to back it up yet still reading nd playing with test net.

If it is an optional wallet, then sure. ...If you don't need to hard fork it to implement that code, and it is simple enough to do with a standard non mandatory updated wallet version release, why not just push it out for us to use real quick, even if it is just a few days. Maybe not everyone will update to the new wallet but it will be good to get feedback, and also help us know how much time we need to give people for them to get updated in preparation for a hard fork. I am sure there will be plenty of people willing to run it to help us make the best decisions. In the meantime we should get everything ready to go for proposed hard fork, and do whatever neccessary testing we can there too.