Topic: [ANN][CACH] CACHeCoin released based on scrypt-jane - page 59. (Read 224435 times)

Our big giveaway will Continue by 30 April,The ECC valve will increase soon,do not miss it!

Cachecoin is now running again on Dedicatedpool.  Sorry about the downtime.  We had to await a new server but all is going now going forward.



CACHE.DEDICATEDPOOL.COM

Mining Information

• Custom stratum/mpos environment
• Vardiff enabled
• PPNLS payout system
• Everything is transparent - blocks, donations, fees.

Server Infrastructure

• SIX(6) SERVERS IN CLUSTER
• DDoS level 7 cloudflare, 5 and 3 stratum, and level at 1 switch level
• 8 Core servers, 256GB DDR3 RAM, RAID 10 SSD
• Ramdisks, memcaches, to make things go extremely quick

Thanks for stepping in Kalgecin,
Now sadly, I just moved around funds last night, and with my current balance and coin age, it looks like I'll only be having a chance at staking in a day or two. I think (but not sure) that every time I had gotten stuck before, it was when unlocked for staking (which should not be happening right now). Anyway, I'll execute the wallet as instructed, have it run at least for a day, then report back to the e-mail provided.
Cheers,
~ Myagui

ok, please delete the debug.log, run the wallet with the commands appended to the executable  lut it run for several hours, then send me the debug.log to [email protected] and your addresses might help to look through the blockchain. There was someone who said will port the coin control but haven't heard from him yet. I'm having very little free time on my hands to add new features at the moment. But I will once i get the time.

Kalgecin,

Is there an update coming for coin control? Reason I'm asking is that I've had some balance & minting unlocked wallet for some 3 weeks now, and 0 PoS blocks. I understand it might just be tough luck, but anyhow wondering if there's anything else preventing me from staking.
Also, I seem to have some problem after a day or two with the wallet open, it will get stuck on some block and sync'ing will not progress any further until I restart it. I've had this happen many times over the 3 weeks time I was trying to stake. Connections are always good when this happens, minimum of 6 peers from what I remember. I'm on Windows 8 if that makes a difference, and not using the wallet for PoW generation. Wondering if I'm the only one having this issue...

Thanks,
~ Myagui

The longest chain is always chosen. But the network might cause latency so you wouldn't receive both chains and other clients already decided on the right chain. And when your daemon saw that the chosen chain has the correct valid values, it switched to that.

Edit: looking at the log on my bot from the irc seems that seems that the chain was longer by one block

Could be the pattern I've seen earlier few times, though it previously resulted in orphaning only of a single block - someone computed a PoS block with timestamp (sometimes several minutes) before PoW block on my pool and submit it later. Client tends to pick blocks with lower timestamps, so that PoS block wins, causing an orphan.

According to block explorer, the chain that caused the orphans ends at 15601, while the chain that was orphaned ends at 15602 (which is longer). Possibly bug in the coin daemon, that it picked the shorter chain? The pool has the most recent client (recompiled once the heartbleed was discovered).

It could be that someone is using PoS blocks to attack my pool, or it could be some bug/"feature" in client, that cause blocks to be generated in a manner that looks like attack in one of 1000 cases (which is what we are seeing now)

I'll investigate it, but I think it won't be easy to defend against it.

singula did you look at your pool stats now? Do you have any ideas why the last 5 blocks are orphans? It is not normal, isn't it?

I've tested the simulation for 10 million minutes (~19 years)

With current algorithm: 332380 blocks was mined, average 30.086 minutes inter-block gap.

With your original suggested "block is twice as longer, we reduce diff" rule, the simulation mined 1030398 blocks, with 9.705 minutes average inter-block gap. Due to mined amount being inversely proportional to the difficulty, this would mean much more CACHe would be mined (more than 3 times the current amount).

With my suggestion (reduce a bit less, only if block size id 6 times the expected block size): 357223 mined blocks, 27.994 minutes average gap.

I tried tweaking the parameters of my suggestion - instead of triggering at factor of 6, trigger at factor of 8 and reduce diff by "factor/4-1" instead of "factor/3-1"

This gives 334947 blocks, 29.856 minutes average gap. Very close to the original block gap.

Or triggering at 9 times the expected block time, reducing the diff by factor of "factor/3-2" (so no reduction at 9, double reduction at 12, triple at 15, ...) - this gives 29.98 minutes expected block size. Also close to the original

I've sent you also a patch by email...

The script used to run the simulation can be downloaded at: http://catcoin.cz/misc/diffsim.pl
(ugly perl script, but works

have you tested?

Yeah, I see someone with over 3Mhs in cach.cz pool. About 55x R9 280x. Not bad this time when everyone crazy about the scam Whitecoin.
Could we expect good news for CACH soon ?

looks like whoever is spiking the hashrate is also dumping them for cheap....

Hashrate is spiking, I guess some people jniw where this coin is heading.

how to r9 280x   ---   

https://github.com/kalgecin/CACHeCoin/commit/8ac8b8bee001238d1b161a940f35037789321a0c
That makes sense. I suppose. I made the change above as per your suggestion

I stand corrected it is 1k cache bounty. And we are adding a 10 cache per day bounty for a promoter of cachecoin.

For what is worth, I have no problem with this. However, I would add that singula's suggestion seems less 'aggressive' on the diff adjusting and might be a good option also. Perhaps some simple (yet effective) middle ground could be found? Either way, it does seem that the current re-target scheme is too penalizing after each Nfactor change.


Thanks singula, no more eye sore from the 100%+ round graph, yay! 


You Mister, get your a$$ over to the "Fib Factory" right now and go get me my 4 recursions, STAT!   

~ Myagui

It is now +114.71 % ... whale bot at 50K satoshis is very low, I suspect more whales will appear soon at somewhat higher prices

Not sure if it is a good idea and I see some drawbacks from this:

* There is about 25% chance (assuming the hashrate is stabilized) that a block will take more than twice the target time and times between 300-600% of nominal time are relatively common. With this rule, it will take about 4 or so blocks to push diff down by factor of two or more, so very son the real block gap will push to perhaps 3 or 5 minutes and then it will start to gradually climb.
* This may be used in an attack to significantly lower the diff and then insta-mine lot of CACHe.

I think this "emergency brake" should trigger at 6 or more times the nominal time (such blocks are relatively rare, about 1 in 64) and the division factor should slowly climb from 6, so for example at 6 times the expected time the factor will be one, at 9 times 2, at 12 times three, etc ....

This will greatly reduce the grinding waiting time after nfactor changes, but still won't introduce any over-lowering of the difficulty at normal conditions.

I suggest testing for at least several days (outside Easter, as many people are somewhere else, not being around a computer) before putting into master. Perhaps set the date for

I can run some simulation how the block would look like if the hashrate is stabilized before/after this change and show the results, so you'll see what impact this change will have.