@smooth:

Sending address via PM to collect my share of the GPU miner bounty (4500 AEON).
Thank you 

@macorcina:

I understand that you can simply move the data folder around as desired, and then start aeond with the --data-dir parameter.
Like so: ./aeond --data-dir <new location>


Cheers!

Here's a ccminer win.x86 binary using the sources provided by Moneromooo : ccminer-cryptonote-lite-beta.zip
It was compiled with support for compute levels 2.0 all the way up to 5.2.
 
I have tested basic functionality (all shares accepted by the test pool) using a GTX 980 card, but have not investigated the matter of optimal blocks * threads setting. A good baseline for anyone that used TSIVs miner for Cryptonight, is to start with the same -l settings, and then explore different values.

Sample launch string (one also provided in the linked zip):

Note the -A switch at the very end. This is the current selector for the lite version, otherwise the miner will run with regular cryptonight.
The pool port above is only for test purposes (not generating coins), and might not be up at all times (ping Moneromooo if necessary).

@Moneromoo : Could I be awarded with the nvidia compilation / testing ?  

Edit: For the joint effort with Moneromoo, I bid my portion of the task at 4500 AEON.

I'm thinking that some social media attention affecting the Poker Stars that gave face to this bullshit, has perhaps more significance and consequence than a lawsuit. Should be some very hard stains to clean up.

Done and done 
ty GingerAle!

Thanks for the heads up papa_lazzarou.  
I'm keeping an eye on translation developments both here and on the getmonero forums. I was not opening up a task just yet as the translation framework was still being put in place, but seeing as things are moving a bit faster at the moment, I'll make a post shortly.

Edit: Done. Now I suppose I need to wait for the respective task to be open, eventually accepted, and funding secured.
@GingerAle, please have a look?  Portuguese Translation
Not sure I'm following the expected procedure there 

Brief read of interest to most Monero hodlers, not for what is stated, but for what is not 
Hacking Team broke Bitcoin secrecy by targeting crucial wallet file

Rewards are changing according to this schedule (PoS):
https://github.com/midnightmdt/midnight/blob/master/src/main.cpp#L1232

There's rewards of 12 coins, 25, 50, 100, and later, 1, 0.5, 0.25...
Every 720 blocks, there's a single one of 100 also.

PS: @midnightwish : I see that my previous post was deleted/moderated. Moving on. Cheers.

The masternodes are working/earning correctly: but as djm34 explained, some of the larger holders, are not paying the masternode fees and instead take 90% of the stake reward for themselves. Masternodes are earning 33% of some stakes, but not earning anything from a bunch of stakes as well.

This problem is twofold, one affecting masternodes, one affecting stakers:
- people running masternodes are not receiving all of their due rewards
- some people are staking with much greater profit than others (almost double)

If this is not a distribution problem, I don't know what is... 

@midnightwish:

Looks to be that a bunch of wallets are staking without properly rewarding the masternode % of the PoS blocks.
Please look into this right away and push for an update that forcibly drops the offending/outdated clients from the network.
Otherwise, this remains a fundamental flaw in the masternode incentive. You can take most of the higher positions on the richlist as examples of this behavior (though not all of them).

On the other hand, if the coin will be 90% mined by the time you manage to get a working GPU miner released, it will probably not matter much at all that you fix the issue with masternode rewards (or anything at all). Would be good if you'd settle some deal with djm34, or any other capable miner developer for that matter. IIRC, OCMiner had said much earlier on, that it would be a 5 minute job to get a cuda version made. He's either lacking the 5 minutes, or perhaps the task was underestimated?

It's nice that you've approached this coin with a new algorithm and all, but if you keep ignoring the current flaws in distribution, there isn't much to expect ahead. One positive impulse right at hand, is awarding bounties for community contributions. I hope you can overcome these few hurdles and drive the project forward.
Best of Luck!

@sp_

I changed your latest from git as djm34 suggested, removing just enough #pragma unrolls to allow compile to succeed. I then compiled fresh with both cuda 6.5 and 7.5. This is the Quark performance I get on Windows / 980:

git-6.5: 19.2MH/s
git-7.5: 18.9MH/s

All in all, looks like a minor drop for me. I'm not convinced that these figures are entirely accurate, as it would take me much longer to do a reliable benchmark, time which I can't afford at the moment. Other algos might be broken, I only briefly checked Quark.


Ha! I missed that one Linux ftw then 

@sp_:

Your latest git does not compile with cuda 7.5 on Windows (and likely not on *nix either). There's a problem with Hefty causing the following error message:

The top men on IRC had also found this error already, and I understand there's at least 2 solutions, cutting out Hefty entirely, or modifying it so that the compile can succeed. I don't think either solution has made it into anyone's git yet. You should stop by IRC sometime 

For those with working versions, so far it looks that cuda 7.5 speeds up some things, and slows down other things.
Mixed results all around, so really just for the adventurous for now...

I could rent my industrial grade chopping gear: well oiled, razor sharp chain, chops away like there's no tomorrow!
The total chopping power is ~15 horsepower at 20.000 RPM, which translates to about 300MH/s DoubleSkein 
Safety Equipment is not included.

Feel free to PM if interested.

Quote edited for brevity.

Which is why so much of the US tech industry has outsourced to other nations, India being one notable example. The best ones do of course get transplanted to whatever location makes their work most efficient, but all in all, the US is a rather extreme reference.

I do agree with your general points however, but for the fact that comparing to any traditional employment reference, will not always make sense, as the bounty taker might be unemployed, still a student, in other words, that employment reference might be out of reach anyhow.

@cjambox:

Compute 2.1 is very old by any standards, and in fact, the likely performance would be so poor, that if it ever worked, it would hash slower that your average modern CPU. I very much doubt that you'll get anyone to support this request, but anyhow, best of luck...

@Thirtybird,

To keep the chain/coin on life support, it would suffice to have all clients/nodes/pools/exchanges, revert back to the pre-takeover codebase last published by Kalgecin, right? I'm not saying that's good or bad, just wondering if that would be enough to at least prevent an abrupt end to cache.

I have no stake here. I do have some fondness over the original coin specifications and it was one of the first coins I ever mined, so for whatever reason, I still keep an eye on it. If the community wants to keep it alive, I'll be available to help on a legitimate and transparent takeover effort.

I would encourage any stakeholders to speak up ... right ... about ... now! 

Yes. By not hashing right to the edge of the allowed clock drift, orphans are less likely to occur.

Hey djm34,  

I understand your logic, but I really don't agree with your take on working for a bounty.

- If the bounty is too low for the possible measure of work, then the bounty is just too low, so it needs to be raised in order to attract developers. Different people will naturally value their time differently, for plenty of reasons and not just the obvious one (quality work = expensive work).

- There isn't someone keeping the bounty for themselves in case full performance is not delivered, those that funded the bounty will simply not have the full expense. It is a community organized service, paid with community funds. Being for an open source release, it would stand to benefit the Monero (and CN) community at large.

Hiring a dev is surely another way to approach the problem, but that also has it's own issues, which you're probably entirely familiar with, even though you'd probably sit on the receiving end of that deal  
Personally, and funds permitting, I tend to prefer the hiring dev approach, but others might feel differently.

PS: I recall that there was some delay in getting the bounty over to TSIV, but it was never the case that the people with the bounty offer did not want to pay him. The discussion (and delay) around the time, concerned performance and support for various compute levels, etc...

Edit:

I wanted to take you up on this bounty, but your offer would only cover an estimate of 0 minutes of my talents, so, no go amigo.
I suggest you raise your offer, say perhaps, > 0?  

@sp_, Epsylon3, djm34, tsiv & others:
Bounty for improved open source Monero GPU miner is opening up again, including partial bounty awards for progressive performance bumps.
https://bitcointalk.org/index.php?topic=656841.msg11772611#msg11772611

Given the performance of existing ccminer (including private version going by the figures earlier posted), and taking into account the effective load on the 750TI while hashing this, there is possibly shitloads of optimizations to be had. In my mind, one quick path to improved performance, is in the lines of shrinking the scratchpad and running extra threads (as mentioned the other day, something like -L in the traditional cudaminer).