Topic: âš’[CGA] Cryptographic Anomaly - The Elusive Coinâš’ - page 50. (Read 226291 times)

Brother3, LOL - thanks for the find!
I made a suggestion to that thread for a new and simple algorithm that should remove the complexity and time travel issues of KGW and if we use it for CGA, it will quieten the jumps in the diff by averaging the block find time so that luck and sudden increases do not make it jump around.

 

Awesome! thank you! Trying to figure out where to put this link... I guess make a Coin Database section...

https://bitcointalksearch.org/topic/ann-btc38com-crypto-exchange-launched-its-english-sites-522458

BTC38.com

CGA go go

Not yet. I will be sending emails today.

Nice find! Unfortunately the proposed fix can still be exploited to a "time traveling attack". They seem to be working it out in that thread so I will keep my eyes on it. 

Voted... We are # 2 right now

Speaking of exchanges, there is a new poll about the next coins to be added at Bittrex: https://bitcointalksearch.org/topic/which-coins-should-bittrex-support-week-3-round-1-521726

I notice the exchanges still have the old logo - have they been asked to change?

Cryptographic Anomaly added to altcoins database
Good luck, miners

I am mining this coin for a while and I am happy to see the rewards being payout more often.

This will attract more miners along the way. DEV your the best!

+1 for all the effort

+1 for bringing that up! I have no idea what it says however lol:p

Ok you two....Stop speaking Korean!!!

I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution?

https://bitcointalksearch.org/topic/kimoto-gravity-well-simplier-alternative-505243

 

That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution.

Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s.

So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s.
However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease.
Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time.

To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.

OK, I had the impression that the mining activity had already risen quite a bit, the pool I am on had mostly myself as contributor a couple days ago while this morning it had increased to more than 10% of the Network hashing rate (around 30Mh/s of almost 300Mh/s) so my contribution had shrunk to barely over 1% of the pool. I thought that to be a decent hash rate.
Also, my understanding is that as long as the network hashing rate is constant, the diff does not change as jumps are mostly caused by changes in network hashing rate - which is a result of a profit switching pool... Without them, diff should be relatively constant unless it is very sensitive to block finding rate, which is a statistical and therefor noisy process by definition
Now that almost all blocks carry around 0.3 CGA reward, there is no reason for pools to switch and I'd expected the block finding rate and the diff to stabilize.
I see still large difference between actual block finding rate and design - for example the 40 blocks period from 64132 to 64172 took over an hour, so that is more than 1.5 minutes per block average, while the design is 40 sec. I didn't check the diff of the intermediate blocks but I am surprised that the finding time is more than 2x the designed value.
I am not complaining, just pointing to possible areas to focus on in a next release - we'll have to accept that the mining will generate
much less coins than we'd expect based on calculation - the payout should already be more smooth than before.

Well at least that is sorted was trippin about those coins the past few days.

Get well soon my friend.

My apologies, the coins are all there but the payout scripts do not appear to be working. Here's my getinfo from the pool wallet, to prove I didn't run away with them:

{
    "version" : 1030002,
    "protocolversion" : 70003,
    "walletversion" : 60000,
    "balance" : 79.57981508,
    "blocks" : 64183,
    "timeoffset" : -2,
    "connections" : 63,
    "proxy" : "",
    "difficulty" : 2.03032485,
    "testnet" : false,
    "keypoololdest" : 1391719795,
    "keypoolsize" : 102,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}


I will try to get the coins to you tonight, but I have a fever of 100.4 F right now and will probably be going to sleep soon. otherwise, I'll fix it tomorrow.

I sent the CGA from my inceptioncraft pool account to my CGA wallet. Ive redownloaded the block chain am on running the most up to date CGA wallet and have even sent coins from other pools to my wallet and had them confirmed.

The coins in my inceptioncraft pool account have all confirmed except the last payout which was probably mined on the forked block chain which is fine its only like .07cga. But the rest is confirmed and has not been received in my CGA wallet after making the payout request.

There is no transaction of the coins being sent to my wallet from inceptioncraft in my wallet nor inceptioncraft transaction records.

Its like inceptioncraft just never sent them to me.