[ANN][CACH] CACHeCoin released based on scrypt-jane

[Walrusbonzo]

I've done what I can to prop the price up. For 24 hr change CACHe is 3rd on http://coinmarketcap.com/, +72.86%.

Now don't fuck it up by dumping on the whale bot. I'm hoping it will now fill in the gaps between 94k sat and 78k sat.

 

[jasinlee]

POS update is in the works and n factor just went up...its all coming together.

[Walrusbonzo]

I've done all I can for now, 650~ CACHe richer

[kalgecin]

Making a forced update to the way POW diff will be handled. New rule: if the time between last two PoW is more than twice the target time (more than 30 mins) diff is adjusted to meet the target 15 min. So if time will be 45 mins, diff will be divided by 3. Sounds fun? I hven't set the time or pushed an update yet, but current target time for the forced update is 20th April 2014 at 21:00 GMT. Will notify the exchanges when the time will be set for certain. Now I'm just checking if everyone is comfortable with this

[jasinlee]

I would like to offer a 10cache bounty (daily) for anyone that has a promotion business for spreading the word for open source alts.

And remember there is a standing 500 cach bounty for zerolib integration.

And on the git there is a test version up for everyone to try with a surprise in it.

[kalgecin]

proposed commit:
https://github.com/kalgecin/CACHeCoin/commit/eee8b963367ccc2846c60a01a78485e74fb1292c
If anyone has objections, please state them. Or errors. submit a pull request if necessary

[singula]

And remember there is a standing 500 cach bounty for zerolib integration.

Wasn't it 1000 CACHe bounty some time ago? Considering the difficulty (zerolib is sort of unfinished .... )

[kalgecin]

And remember there is a standing 500 cach bounty for zerolib integration.

Wasn't it 1000 CACHe bounty some time ago? Considering the difficulty (zerolib is sort of unfinished .... )

I think it was 1K

[singula]

Making a forced update to the way POW diff will be handled. New rule: if the time between last two PoW is more than twice the target time (more than 30 mins) diff is adjusted to meet the target 15 min. So if time will be 45 mins, diff will be divided by 3. Sounds fun? I hven't set the time or pushed an update yet, but current target time for the forced update is 20th April 2014 at 21:00 GMT. Will notify the exchanges when the time will be set for certain. Now I'm just checking if everyone is comfortable with this

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.

[singula]

I've done what I can to prop the price up. For 24 hr change CACHe is 3rd on http://coinmarketcap.com/, +72.86%.

Now don't fuck it up by dumping on the whale bot. I'm hoping it will now fill in the gaps between 94k sat and 78k sat.

 

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

[myagui]

Making a forced update to the way POW diff will be handled. New rule: if the time between last two PoW is more than twice the target time (more than 30 mins) diff is adjusted to meet the target 15 min. So if time will be 45 mins, diff will be divided by 3. Sounds fun? I hven't set the time or pushed an update yet, but current target time for the forced update is 20th April 2014 at 21:00 GMT. Will notify the exchanges when the time will be set for certain. Now I'm just checking if everyone is comfortable with this

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.

As for the shares - it is true, that the round info graph compares your rate to pool rate (which is you + rest of the pool) and this does not make that much sense for a pie (or round or similar) graph. I've fixed the round info graph to compare you vs. rest of the pool.

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

POS update is in the works and n factor just went up...its all coming together.

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

~ Myagui

[jasinlee]

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

[kalgecin]

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

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

[ECF]

http://www.ecoinfund.com/images/logo.jpg

Website  |  Twitter   |  Bitcointalk

Hi,Cachecoin Community

We have added CACH to ECOINFUND.（CACH/BTC,CACH/LTC）
Multi-language Alt-Coin Exchange,Fast, Secure and Trustworthy.

Big ECC GIVEAWAY before 30.April:
Tweet this green text on your own twitter account and recive 50ECC（ECC Details）:

ecoinfund.com |New Exchange,multi-language support,Earn 50ECC(fee shares) by every retweet before 30 April,don't miss the train!

Pls post your twitter link and Ecoinfund ID on our bitcointalk thread or pm us.
ECF Coin (ECC for short) is the fee share program launched by Ecoinfund.
Ecoinfund will commit 50% of trade revenue to ECC program. (highest on market)
Giveaway more infomation:https://bitcointalk.org/index.php?topic=501030.0

Happy trading !

[vovan115]

how to r9 280x   ---   

[jasinlee]

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

[kalgecin]

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

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

[AizenSou]

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

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 ?

[kalgecin]

Making a forced update to the way POW diff will be handled. New rule: if the time between last two PoW is more than twice the target time (more than 30 mins) diff is adjusted to meet the target 15 min. So if time will be 45 mins, diff will be divided by 3. Sounds fun? I hven't set the time or pushed an update yet, but current target time for the forced update is 20th April 2014 at 21:00 GMT. Will notify the exchanges when the time will be set for certain. Now I'm just checking if everyone is comfortable with this

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.

have you tested?

[singula]

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