nTime IS when you completed the block.  So yes, you definitely can choose.  and nTime is part of calculating the hash.  No need to actually submit a block at a specific time, just vary nTime as needed.

The code is in your own client - just call getBlockValue ?

You don't need to determine the next difficulty, Anomalies are based on the _current_ difficulty, which becomes evident when you read the source code (and it seems, the OP in this thread even says that pretty clearly).  Basically, (anomaly? yes/no) is determined from height_of_block and difficulty_of_finding_THAT_block.  Not difficulty of finding the following block.

You can influence difficulty by abusing KGW.  If you look into how KGW works, it's entirely based on nTime - block discovery time as a unix timestamp.  Thing is, nTime is very flexible - you can specify at least + or - 100 seconds and it will be accepted by the network.  There is nothing random about nTime - it's chosen by the miner... and nTime is "when" someone solved the block

True, at diff < 3, only every third block can be an anomaly.  This in and of itself is pretty amusingly exploitable by miners - again, why would you mine the obviously worthless blocks?  Let someone else (a fool it seems) waste their hashing power on the 0 reward blocks.  A smart pool operator would know this too - and would be redirecting their hashing power to another coin (with or without telling their miners).  If you can't find a valuable block anyway, then why bother - you can simply _say_ you found a worthless block once and a while, meanwhile keeping the litecoin or dogecoin or whatever you are also mining for yourself.

If diff > 3, then every block can be an anomaly, and therefore all an attacker needs to do is raise the difficulty above 3 while holding 51% of the hashing power (setting the difficulty as desired would be fairly easy - again by abusing KGW and nTime), to ensure every block is an anomaly.

Anyway, I would honestly prefer this coin succeed.  I have made it pretty clear how to selectively mine this coin at this point, and I decided I would prefer not to release the few lines of code required to predict the next block.  CGA seems like a neat idea - what brought me here is that I was considering mining it, but as I usually do, I dug thru the source code first.  Which brought me to this conversation now.

I do hope this coin could succeed, but unless a huge change is made to the protocol, at some point, someone definitely will exploit this huge flaw.

Okay... so the code I threw together seems to suggest s4w3d0ff led me a bit astray... (and he seems to be leading everyone astray by talking about 50% mining power still leaving you with a coin-flip probability of finding a block...)

Unless I missed something (quite sure I did not), every block appears to be predictable - anomalies occur based on the CURRENT difficulty and the CURRENT block height... not the upcoming difficulty.  So there is no prediction or calculation of nTime required to determine the value of future blocks.  My testing indicates that you can reliably predict if the next block is an anomaly or not, every time, just by calling GetBlockValue from a newly created API function, using block height as a param.  No fancy code is required, and KGW doesn't even come into play here.  Anybody should be able to add a "isNextAnomaly" function to the daemon quite easily.

This means 2 things:

If someone had enough hashing power to build off their own chain (aka, 51% of the network; or using selfish-mining principles, as little as 30% of the network), they could predict the nTime required on the next block that would result in the following block being an anomaly.  Using this system, and by only building on your own chain, you could cause EVERY block to be an anomaly.  A would-be attacker (say, multi-pool), could mine the network, orphaning everyone else's blocks, and get a payout on every block at the same time.

Furthermore, there is absolutely no reason to mine worthless blocks (non-anomaly) - if you wanted to mine CGA, it makes the most sense to mine litecoin (for example) until the next block is an anomaly, and then switch to CGA, switching back as soon as a block is found by the network and the next block is not an anomaly.  The diff is low enough that solo-mining would likely find this fairly effective and profitable.

If pools, or someone solo-mining felt like it, they could also pick nTimes selectively and cause the following block to always be an anomaly (wouldn't necessarily benefit them, but would significantly increase the number of anomalies that occur).

Simply put - no.  If I have the longest chain, it must be accepted by the network.  Adding restrictions around this essentially destroys the openness of the protocol, and would require some form of centralization (defeating the purpose of crypto-currencies and proof of work design).

Why? This is well known stuff... if a dev doesn't know this about their own code, then there is certainly an issue.

Anyone can find this out by reading the source code and running a few simple tests.

Queue payout style system sounds smart to me.  And I also agree that a fee increase would be warranted, should this be implemented.

Read 1 page back - I talked about this with s4w3d0ff in this thread yesterday.

I highly doubt there _is_ a fix possible, at least without significant changes to the system.  When you are hashing a block, part of that of what you are hashing is transactions - one of those transactions if the "pay me for this block".  Unless you re-write the entire protocol to handle this differently, I see no easy way to make the reward unpredictable.  Every "random" block reward coin suffers from this - Doge, Lotto, Moon, Leaf, etc.  However, in the case of CGA, it seems potentially devastating (if it catches on, who is going to mine a block they know is worthless?).  And you have to presume something this obvious is going to catch on.

Not quite sure what you mean.  It could allow someone with enough hashing power to 51% the network and cause ALL blocks to be an anomaly.  Or it could allow a smaller miner to predict if half the blocks will be 0 or 1, and then intentionally cause the other half of blocks to be 1 ALWAYS.

Well, let's wait and see.  Normally I would agree, but the dev seems legitimately intent on holding these funds and using them for development and coin advancement.  I would have preferred 0% premine, or something more reasonable like .5%, because it requires no trust.  But at this point, I highly doubt the dev is going to dump on the market.

I simply do not understand your logic... I would be saying the same thing if I got paid or not, which is 'as long as I get paid eventually...'.  Somehow I think you wouldn't be bitching if you were one of the people that got a payout.

Anyway, PW isn't running a business paying employees.  He's paying contractors - and lots of companies delay paying certain contractors for whatever reason.  So you're analogy doesn't hold water, sorry.

As far as I know, there is no proven way to make a block reward not predictable and not miner selectable at the same time.

It might be possible to use the discovered blockhash to choose reward, but that would likely require some significant changes to the underlying protocol.

More so to simply show that this coin design is (unfortunately) inherently flawed.  I am sure there are already people exploiting this 'anomaly' (oh, pun lol).

FYI: If have been digging into CGA code a bit more, and if my tests are successful today, I plan to release code that will allow predicting and forcing anomalies on CGA.

It will look like this:
- An odd # block is found.  The script can immediately tell you if the next block is an anomaly or not.
- An even # block is found.  The script can immediately tell you what nTime values to use to GUARANTEE the next block is an anomaly.

I have no problem with an occasional delayed payout - PoolWaffle always comes thru.

That said, I would be happy to see the fee raised a bit - to maybe 1.5% or 2%.  Seems more then fair, and still the lowest I have seen (specifically when nobody offers a truly comparable service right now). PW having more $ on hand to potentially expand operations, handle late payments, or whatever, just sounds like a decent idea.


Reddit is way more annoying to following, IMO.  It takes a whopping few minutes a day to scan thru the new posts in this thread, and keeps everything centralized.  I am glad PW keeps his communication here - I am sure it kills less of his time.

I doubt "manual" means actually entering numbers manually lol... more like "manually running a script".

And I would presume it would run by largest balances first, but who knows - could be any given sort order, but based on me receiving a payout, I'm guessing it has something to do with those higher up the chain.  Or maybe it was just random.  Who knows.

Anyway, PoolWaffle obviously still has the "Note: Payouts are slightly delayed" on the site for a reason - I am sure everything will be cleared up in around 12 hours.

Just a guess, but I bet the larger miners got paid, although this wasn't intentional.  Looks like a bunch of coins got exchanged at the same time as cryptsy finally sent the bitcoin payment, payment went out, but because there was so much exchanged balance sitting on cryptsy, there wasn't enough to pay everyone.  I highly doubt this was intentional - payout script probably ran and cleared people's balances until there was no BTC left.

Logical a payout script would start at the top and work down (simple sort order), so smaller miners accidentally not getting a payout does make sense.

Anyway, it really shouldn't matter - everyone will get paid tomorrow, and then you can just smile about a much bigger then average 1-time payout.

Heh, it's what the 40MH/s+ on the big profitability switching pools do to all the variable rate coins.  I just find it interesting that the hashrate on CGA seems so steady given this.  But maybe it's not - I think I'll try running some stats calculations tomorrow to determine if there is a potential difference in the discovery rate of anomaly blocks vs non-anomaly blocks - I have a feeling it'll be statistically significant.

Actually, I got a payout at 2014-02-23 02:xx.  So that does seem a bit weird.

Anyway, just hang in there Clocker, you'll get a payout tomorrow I am sure.  Seems like some payouts just got delayed or something because of all the issues.

I've been around here for a long time, and sometimes the payouts are late, but they always seem to come thru.  (PoolWaffle kinda rocks that way .

---

@PoolWaffle:  Have you ever looked at [CGA] Cryptographic Anomaly?

I was just reading thru the source, and realizing that it looks like you could intentionally cause all of your blocks to be worth 1 coin (most blocks are worth 0, some are worth 1), by picking your nTime carefully.  It is definitely low diff, but seems valuable enough that it might be worth throwing some hash at briefly and dumping on the markets.

Hm... well, might have to play a bit with this tomorrow.  To me, it seems there is a sure way to ensure you're never mining a worthless block.  Which then seems like it would make those people mining the worthless blocks nothing short of fools.  I also presume it's likely someone else has already figured this out.

At a minimum at least, you could tell if every 2nd block is worth mining or not, and if not, mine Litecoin or something instead of wasting your hashes on a worthless CGA block.

See the edit to my last post, since you have a fair bit of play with nTime, and from my quick analysis of KGW, it seems you could make EVERY block you find an anomaly.

The only unknown variable to calculate the diff of the next block seems to be nTime...

I will have to dig into that tomorrow.

Also, as far as "hopping on" only for valuable blocks - that's exactly what smart multi-pools do with Doge, Leaf, Moon, Lotto, etc... since all of their block rewards are seeded from the previous block hash, and are therefore predictable before the block is mined.  Based on design, you either have to known the BlockValue before hand, or else it is likely possible to choose what block value suits you - I have yet to figure or see out a way around that, which is what brought me to think about CGA.

Ah I see, so you're relying on KGW to change the diff every block and therefore make the diff input to fmod(block, diff) unpredictable.

Interesting point there tho... I will have to dig into KGW a bit more - is it based on ntime or broadcast time?  If I recall correctly, it's purely based on nTime differences (but I could be totally wrong).
If nTime based, then you could calculate the nTime required on the next block to produce an anomaly, and use that nTime, no?

Edit:

Yup... it definitely looks that way - so... here's what I'm thinking:

Kimoto's gravity well uses:

As it's key adjustment variable... now, given that GetBlockTime is:


That means unless I am missing something, it should be possible to make EVERY block you mine an anomaly by carefully selecting the nTime you use on your block.  Mind you, this is a rather quick thought and I definitely could be missing something.