Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained] - page 136. (Read 1369778 times)

Orphans:
Worst case would freeze the mint network and block syncing for a lot of users.
Especially for new People syncing the 1st time.
Best case , then no problem.

FYI:  Mint already has orphan issues, they are just not noticed as much, due to the fact that so few are staking 24x7 .  For example at the moment only 3.2% of coin are staking, so your orphan rate is lower.
Your staking rate changes daily and on days where you have over 10% staking your Orphan rate is higher.
Easy test , start a new mint wallet and sync it from scratch when your staking rate is higher, you will notice it freeze up on blocks during the sync, check the debug.log file and you will see the orphan problem.

If your timedrift is set too low for a 30 second block and your staking rate improves to 20 or 30 % , your orphan rate it gonna go sky high, unknown if high enough to block syncing or not.
So a increasing/normal staking rate should be a factor in the final decisions.

 

This is the issue... If you drop the timedrift window down, you increase the risk of a network freeze; and it can thus reduce the "randomness" of who is going to be getting the next block, by excluding some people who's clocks are not accurate.
The thing to find out is how big of an issue is this? Do we know what the average, or median divergance typically is from keeping an accurate time for a large pool of nodes? If 98% are within 2 minutes, then it makes sense to me to do it. But does anyone know this information? How can we know what a good timedrift is? Is there anyway to track this data?

Are there any sort of configuration settings that can be done to improve this, and make it more accurate.

One thing to find out is what % increase in orphans will it cause? If it increases them by a mere 5% or something then it is probably acceptable. Is there anyway this can this be tested?

So if we all keep our wallets online for minting it will help. Good to know. We need to let everyone know to do this.

What would be the downsides of setting the timedrift to 1.5 minutes?  Orphans? How bad would it be? Do you think it would really be an issue? Any adverse side affects?

Edit:
Also, what would be a good network weight level needed to prevent this?

Listen i am a real scrub when it comes to code and everything around it, but after reading this discussion. Is it possible to let the wallet check the real time and match it with the PC time? And if this is way off unable it from minting.

just some random thought, and again i don`t know what is possible within a wallet and what is not.

Network weight will mean higher difficulty, and higher difficulty means it will be harder to get it into this type of spiral to begin with.

120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180

6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.

Just some food for thought.

How would pulling it down to 6 minutes make a lot of difference? If you say you pull down the difficulty, rinse and repeat, what difference does it make? It is the same effect right?

Edit:

I get that loweribg it to 6, 2 or 3 minutes will make it harder to pull down the difficulty,, but will it be enough to stop it from perpetually going lower? How do you stop difficulty from perpetually going lower by using that technique? What would be a complete fix?

Edit2:
How does network weight affect it? Are you saying if the network stake weight was higher, this issue would be mitigated?

Not correct because PPC does not have the exact same difficulty adjustment code. You could stake as many blocks as you so please in the timedrift window. They do not need to have any chronological order according to the network rules. I could stake some MINT that is 30 minutes into the future and it would bring the diff way down low because the network thinks it took 30 minutes between finding blocks. The next block could come in at normal time, but since the code has a section that doesnt allow the diff to calculate as a negative number, the network thinks that it took 1 second to find the next block... thus jumping difficulty up a little bit, but not near as much as it dropped. then i could publish one another 30 minutes in advanced, and rinse and repeat until difficulty is next to nothing.

Pulling it down to 6 minutes would make a lot of difference. My personal recommendation would be 2-3 minutes. With 30 second block times, and the terribly low network stake weight that MINT has, it could really be played with (and I thought about it before, but decided not to get into the business of having too much fun with other peoples money).

Anyways, keep up the discussion, it is interesting.

Okay, well since mintcoins has faster blocks (approximately 30 seconds) then it makes sense to reduce the time down.

If peercoin is 2 hours, with 10 minute blocks,  it will have a limit of 12 blocks ahead. So in order for mintcoins to be comparable, we should have it set at 6 minutes. Mintcoins should be 6 minutes with 30 second blocks. It will then have a limit of 12 block ahead .

Correct?

Excuse me, it is my normally playful ways, not meant to insult or degrade.
Take no offense, it's just how I am.  

Time Drift was created , because not everyone PC clock keeps accurate time.
Without it a network could freeze up due to lacking stake-able blocks.

Mint makes blocks every 30 seconds, which means their should be 120 blocks per hour.
Your Time drift is 2 hours or 240 blocks.
When someone uses the timewarp to cheat , their block timestamp could be up to 200 blocks ahead,
when mint generates the difficulty setting it looks at those timestamps, and think the difficulty was too hard and drops it so that the next block can be found in a 30 second timeframe. This dramically lowers the difficulty.

15 seconds is lower than your generated blocks ,and would cause a massive increase in your # of orphans.
FYI: Mint already has issues with the orphans , that is what is causing new people to have so much trouble syncing, but that is an issue for another day.

More people staking can not stop the timewarp attack as no matter the number, it lets the attacker jump in front of them for staking.

As why 2 hours was chosen, we probably have to PM Sunny to find that out.

FYI:
If dropping your timedrift to 1 minute was a major concern, you could always change your block time to 1 minute and get away with a timedrift of 2 minutes.

 

You don't have to mock me. I'm trying to learn and understand.  If it is at risk I want to be sure, not just create FUD. Answering my questions would help. Why is 2 hours too long? Why is 15 seconds too short? How do you know what the right balance is, really? Why do we have to have to allow any amount of time at all? What factors go into affecting it? Does more people connected and staking help prevent against that sort of attack? Mintcoin is pretty established, just comparing it to some other coin that nobody used, is not the same for comparison IMO. I just want my questions answered, because obviously if there is a threat of making it too short, that would be bad too. Maybe 2 hours is actually enough. I'm trying to understand this issue. What is the reasoning for why 2 hours was chosen before?

LOL ,

Presstab discovered the issue, if he says your coin is at risk.  Then It is.
He could tell CM how to do it , and then observe the block explorer for the results.
Difficulty halving and her mint address getting all of the staking will be your proof.



 

I am still not convinced. I really like the way the coin is right now. Is there a way to test this attack on a mintcoins testnet, to really examine the risk? I am not for hard working anything if it is not absolutely necessary. At this point I'm not convinced that this won't have some unforseen consequential side effects that would be detrimental.
How do you know 2 hours is too long and 15 seconds is too short? It seems really subjective, and if it affects minting rates and difficulty that is a concern. I like the balance mintcoins has to offer on its parameters. How do you know how much to drop it? What would be the problem of making it limited to say, 5 seconds?

It is up to your community, the timewarp attack is very simple to do and can even happen by accident.
If it does happen, the signs are your network difficulty will drop like crazy, up to ½ per block until it is a very low amount, and if you check your block explorer , only a few or as low as 1 mint address will be getting every stake in a row until they run out of stakable coins.

Now this will not harm transactions as they will go thru normally, your number of blocks created will also be faster than every 30 seconds, which will cause your network to give a higher interest rate than designed.  

The biggest dangers are the difficulty drop which will weaken network security , possibly allowing an attack that is currently blocked. Also almost no one else will be able to stake except the ones running the attack which is a bad PR issue as it destroys fairness in staking.

But with that much control of the blockchain , other dangers could arise , such as a person doing that on 1 side to set the difficulty really low , and then bringing up another wallet for a 2nd attack , with sightly higher difficulty and length and overwriting your blockchain after a few days, which would erase all transactions before the original attack started.
That would be worst case as transaction history must be protected at all costs.

FYI:
Fix is mainly just changing the timedrift from 2 hours to a lower amount.
Less time involved , the less the difficulty will drop.

"While the altcoin markets were not as exciting as they usually are, there were still gains made this week. Altcoin markets seem to be reflecting similar trends to Bitcoin, with the interest in trading declining. The coins that received higher gains this week were of lower volume, like Mintcoin, with its approximately 90% increase.

While there were altcoins that had greater earnings this week, they were all of minuscule market cap and volume which could have been the work of just one entity controlling the market. Mintcoin is 15th on the list of 7-day gains but is the 1st to on the top 100 coin market capitalization list.

While Mintcoin does have a low volume in comparison to bigger cryptocurrencies like Bitcoin or Ripple, there does seem to be a continuing demand for Mintcoin."

http://bitcoinist.net/bitcoin-market-wrap-621-628-btc-holds-steady-mintcoin-demand-increases/

What a press release site that takes releases from mintcoinofficial.com http://mintcoinfund.org/ and other 3rd party websites that include Mintcoin in their podcasts, articles and imagery?

I would not be able to maintain this one other than hosting and wordpress upgrades maintenance so someone else would have to claim responsibility on collecting the content - I can of course email that person when I submit content across the spaces.

Someone else would have to design it.

If I understand correctly this is what presstab is offering to work on for Mintcoin as he has found a fix on his other project HyperStake. The thing is it requires a hard fork - something I feel is extremely important to make sure it is done; however I am wondering if it is something deserving of an immediate hard fork or if we have some time to let the new wallets take one or two times before requiring the upgrade?

FYI:
Some are looking into it, but peercoin has not responded yet?
https://github.com/ppcoin/ppcoin/issues/82


 

Problem:  BlockChain Bloat  
Blockchain becomes too massive and takes too long to sync even with a bootstrap.


Solution: Genesis Block    
No matter , 30 seconds or 10 minutes for block time, eventually they all are going to be too big.
The only real solution to blockchain bloat,  that I can currently see is what is called a Genesis Block.
Once every 1 or 3 or 7 years, depending on how fast the blockchain grows,
a new Genesis Block is created that holds every address & updated balance, and from that point on the Genesis block becomes block 0 of a new blockchain removing the bloat from all future syncs.


 


FYI:
Fixing your Timedrift issue will require a Hard Fork, if everyone does not update , it still leaves you open to the timewarp attack from anyone on the older client.

My question is, why doesn't peercoin do it then? Peercoin has one of the greatest PoS developers in the world...Sunny King created Proof of stake. Obviously there is a reason why he designed it the way he did. Is there any discussion that includes Sunny on this topic? I for one would like to hear his take on this issue.

About 2gb