Well what are the reasons for or against an N reset?
And why would we do this instead of just starting again with a new coin?
I'm not sure why you would even think this a valid strategy. Starting over on N IS making a new coin.
We don't jump to NF=18 for a whole year, so don't start stocking your survival shelter yet. By the time it arrives, YAC will have been on NF=17 for nearly 1/3 of its existence and it will just be "normal". Is NF=17 hard on our GPU's? It is. Is it any different from any NFactor change in the past? No. Every change in NFactor is met with confusion, frustration, and HW errors. This difference is that we have years of understanding now instead of days, or weeks, or months.
We've known for a while that CPU would become competitive to GPUs again at this NFactor, we just need to figure out how to keep the hashrate spread out so that there's no 51% network ownership. We had this situation for a long, lone time with coinmine.pl having >51%, but everyone was okay with it because that's where most of the miners were. During that period, solo mining was difficult because the pool would get most of the blocks and people not on the pool would see orphans. Now, we have someone who has quite the mining capacity, but he's solo-mining, but only during specified hours, leaving the pools with orphans. It's quite possible that this is not even malicious intent (other than likely using computers that aren't his or hers), but just that much hashpower that it dominates the network.
+1!!!
It looks like we can take the day, but this unknown miner still owns the night (Pacific Time).
In the spirit of not wasting hashpower on orphans and reorgs, I think people should direct their miners on a daily routine during the time this guy(s) is not active. We want everyone who mines YAC to get richer, not poorer at their own expense for this guy's benefit. It is a weird workaround that I think works until 'we' can gather more hashpower. I would think it would be best to time any changes during this time as well to help prevent a fork?
It would be great to see more small miners at
http://yac.erlog.pt/. NineEleven, thank you so much! Hashrates are now displayed in hash/s. Joe_Bauers, thanks for displaying that info on the website.
Looking at explore.grokonet.com, I'm noticing a lot of extremely small PoS blocks. It seems a bit odd to me considering I still have a lot of larger inputs ready and waiting to be staked, but perhaps that is an issue with my wallet processing slowly? I'm reminded of your comment senj, "Currently it does not give different trust value to PoS blocks with different stake, as it was before no-two-consecutive-PoS-blocks fix." Perhaps that is a factor as well?
By the way...
I have a pretty good feeling about what is happening now:
We build PoW+PoS+PoW chain with a trust of 10+11+20=41 for example.
Minutes later attacker broadcasts PoW+PoW+PoW+PoW+PoW (10+10+10+10+10=50) and kicks our blocks out.
But the real problem is that PoW difficulty in our branch get's adjusted towards 2 minute spacing when PoS block arives. On the other hand, attacker's blocks are stil one minute apart, so he is mining on lower difficulty, has more time and is able to overtake us eventually (before our POW difficulty readjusts back). It might be that in addition to having more hashing power.
Just one more thing to consider while refactoring GetBlockTrust method.
Really? This concept seems to bolster the value of your changes--increasing PoW difficulty following PoW block. I hope that can be implemented, released soon.
