- bump -
Preço atualizado!

I'm skeptical that it is a botnet.
These normally gravitate towards coins with significant enough daily trade volume, and those with hashrate high enough that overall difficulty is not substantially affected. With AEON today, both of these factors quickly make the mining returns unprofitable, generally speaking. Though, perhaps that is why he/they is/are mining on Minergate? 

I can hardly imagine the urgency of mining so many coins, that a single individual/miner would assign so much hashrate that he is single-handedly doubling the difficulty. This person would earn a lot more coins, by mining with half the hashrate for twice the duration^[1]

Perhaps his hardware/system access is such that he must point his hashrate in "all or nothing" fashion? So maybe he hops from one coin to another, in order to diversify his mining returns. Just wild guessing though, I do find this interesting.
 
^[1] Unless he is somehow anticipating some paramount circumstance that would render mining much less rewarding, in a very short time... which doesn't make much sense to me

Yes, nf:15 will differ. I don't have the settings for that one though.
On large nfactor scrypt-jane, Linux is better by at least some 20%.

It's been a while, but I think these were my settings for Scrypt-Jane:16, on Windows.
One config aims towards max efficiency, the other one towards max hashrate:

cudaminer -a scrypt-jane:16 -L 8 -b 8192 -l t64x2 -i 0
cudaminer -a scrypt-jane:16 -L 16 -b 8192 -l t64x4 -i 0

There are much better settings/performance on Linux though.
Happy Mining!

Worse. Add the transaction fee to that... 
Pasted from the BTC withdraw dialog:
WD Fee: 0.00100000 BTC  +  0.50% BTC

I had voted some, and was looking to get some more voting action on Craptsy. However, I just realized that they killed the trading fees, and instead now have a 0.5% withdrawal fee. I'm done with Craptsy.

We're surely bound to better places though (hopefully Poloniex sometime soon).

About memory intensive algos: any brainiac tried a LUT approach yet? In short, reducing memory access and doing additional compute work instead... (IIRC, the prime example of this is with scrypt-jane, and possibly some other flavours in cudaminer).

ETH can probably run much faster on the high end cards if some of the memory access can be replaced with computation.

I'm referring to how some pools weight share value (or share count), in a non-linear relationship to share difficulty. An average of 1 minute per share is not really a spiky graphic, unless you're zooming in on some 5 minute window  
When you run into a pool that allows fixed/permanent difficulty, really, try it out. See how the graph looks for a few hours on auto difficulty, versus a fixed higher difficulty (but not too high). Yaamp was one pool where I noticed this, when it was around...

Sidenote: I do have decent (small) latency to any/all of the pools I use. For people with bad connections and high latency, high share difficulty will also increase the rejection rate (invalid work, submitted too late).

Edit: There's also the advantage that with fixed diff, you don't get as many job restarts due to the constant difficulty adjustments. It could well be that I was seeing this benefit (of fixed diff vs variable diff), as opposed to a benefit of higher diff shares per se. I'll post some comparative results when I'm at a pool that allows me to mess around with both methods.

As someone else corrected already, it is just the starting diff, so the only use on Nicehash is to prevent the slow difficulty "ramp-up" time when you 1st get connected.

Personally, I tend to aim towards high'ish share difficulty also on pools that allow a fixed/permanent setting, as over time, I've built the impression that pools are not linearly increasing share-count with share-diff. Which makes sense really.
A miner sending a gazillion low diff shares takes up a lot more pool resources, than a miner with identical hashrate but sending just a few high diff shares. In any case, I'm not sure it matters much.

Looks like someone got tired of waiting for a dump, decent market movements on Yobit recently 

Would be great if we'd get into a larger exchange, it's tough to reach a wider audience if we're stuck with Yobit & Empoex. Baby steps maybe. I'm trying to round up some modest funds for a few craptsy votes using craptsypoints, but looks to take me a while.

What other exchanges do you guys suggest we throw votes at?

You didn't say anything about running separate workers. I don't understand how you can tell that the problem is global, without having looked at individual worker stats. This is particularly important since you mention that also AMD rigs are doing the same.

It's most likely that it is a single rig having trouble, not all of them.

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

For individual worker shares, all mining into the same BTC addy:
-u yourbtcaddy.worker (replace worker with some unique worker name for each rig)

Another way of finding out which rig is causing trouble, if it is indeed a single rig, is that you could point one rig at a time into some alternate btc addy, so that you isolate the stats for that rig alone. Measure up to the 2 hour point or so, and move on to the next rig. With individual worker names you should be able to monitor individual rig stats while keeping the btc destination the same.

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Have you confirmed if restarting ccminer on all the rigs achieves the same result (high hashrate & low rejects) as the full reboot?
The only other thing I can think of, is the case of your rigs all heating up beyond the optimal performance sweet spot. You could try lowering clocks or increasing fan speeds, and see if performance settles at a higher figure after warming up.

TSIV's works, as well as sp_ has a private version with some small boost (windows binary only).
What trouble are you having with TSIV's?

The dreamer in me thinks that before either of those exotic scenarios, we'd have free & universal access to electricity, 'cos you know, Sun ... and non-destructive, non-pollutant energy storage methods ...  Anyhow ...

I do agree that PoW has flaws, in my limited understanding of the matter.
My question however, was to how DPoS compares, specifically:

I noticed that the earlier link points to an interesting discussion about DPoS, will read up on it.
Cheers gents!

Thank you r0ach & others for comments, this thread is a really good read.

If I understand correctly, in Bitcoin/PoW, any miner can opt for not delegating his hashing power, and yet remain an active participant. I know most people do delegate their hashing power, for various practical and economical reasons, but still, it is not a mandatory position. The miner has full authority over its own hashing/voting power, and unilaterally decides (if he delegates to a pool or not).

Is DPoS comparable, in that the holder/staker has authority over the decision to delegate or not delegate his hashing/voting power, and remains a participant in equal standing regardless of his position towards delegation? I'm definitely not familiar enough with DPoS, would appreciate any pointer to a meaningful intro on the subject.

I haven't used Craptsy in a while, but I figure I can move some volume around there and hopefully round up a few of their CraptsyPoints (good way to build a decent vote count). Everyone vote counts, let's get moving peeps! 

Both Ziftrcoin and Spreadcoin (not sure about the details on this last one), have incentives to run full nodes.

I can speak to the case of Ziftrcoin as I am somewhat familiar:
With Ziftrcoin, miners can opt to include some knowledge proof in their mined blocks, that establishes that they are running a node. When this option is enabled, the respective miner can claim a higher block reward (5% iirc).
As I understand, this proof method (and thus the "extra" reward) are not technically possible when pool mining, or would otherwise imply that the pool miners are capable of stealing any blocks found by the pool.

I think there is some whitepaper on this, too lazy to go look for it now...
Anyhow, here's one important link with descriptions about the system:
https://www.reddit.com/r/ziftrCOIN/comments/2wlg5l/ziftrcoin_mining_update_proof_of_knowledge/


While I like the idea, 5% strikes me as too small of an incentive. Most miners seem to go for a pool setup even if the long term rewards are worse than solo mining, for whatever reasons, variance, etc. In any case, this is a system that only incentivizes full nodes, if said systems are already miners. I would argue that an ideal approach, would somehow find a way to reward full nodes regardless of them being also miners or not.

Para Ethereum claro que sim (maior exemplo será este: http://www.augur.net/), mas seguramente haverá outros. Eu não tenho acompanhado devidamente. Para Shift penso que ainda não há nada, por agora é utilizada exclusivamente como moeda virtual (especulação, etc).

Em principio, permite correr as mesmas aplicações/contratos distribuídos que sejam feitos para a rede Ethereum, com um mínimo de adaptação. Não sei se isto responde à tua pergunta...