Topic: [ANN][YAC] YACoin ongoing development - page 172. (Read 379868 times)

Actually, don't expect too much because we know things are changing, no one knows which is the end. But we can see the direction ahead that is innovative things not copycats. That's why we need to pay more attention on the development of the infrastructure.

I own 10K of them, not much. And I'm eager to promote it, too.

How do I fix the old checkpoint message?

Windmaster - Thanks for the the checkpoint fix.

I'm not even sure that people mining it with gpu is a bad thing in long run or even now. Price needs to go up for cpu mining to be decently profitable and gpu mining might be the one that will keep things moving until then.

And it was always expected that gpus are going to jump in at some moment. Despite some problems it was still a coin where people without lot of gpu power could take the bigger piece of pie in early days than it's case with other coins.

There was OneCoin, but the developer couldn't figure out how to compile for Windows, and gave up.


I have trouble parsing this sentence.

My main interest here is determining the feasibility of yacoin moving forward, as I have a decent amount of them. It's great that a development community is forming around it, as that's a huge plus, and IMO required for any "lasting" altcoin. However, I believe that this coin still needs something to set it apart from the rest if it is to be substantially successful. It currently has that. But how much of that is due to the intrinsic technical properties of the coin, and how much of that is due to the fact that no GPU miner is publicly available yet? THAT is the key question for me.

Therefore, I'm very interested in the effectiveness of GPU mining in the months and years moving forward, especially as it relates to CPU.  If we can at least keep the performance advantage between CPUs and GPUs < 5x or so once N >= 2048 (in a few months) then that may prove to be good enough. This is why any technical data on hash rates with various N sizes would be very interesting to me, especially as it compares to a CPU.

Right now, GPUs are clearly more effective than CPUs, but the # of users mining with GPUs appears to be very low (1 or 2? ). If a reaper/cgminer YAC kernel is made available though, that will change very quickly.

I can't believe that hasn't already happened.

Also - is the mtrit in this thread famous mtrit or famous original mtrit?

Only the last page or two, and there's a bunch of client-related stuff dealing with checkpoints and the warning the original client is showing mixed in.  Certainly a discussion about GPU mining and the first people to post hash rates and implementation details is of interest to ongoing YACoin development.

Just my 2 cents here:

Congratulation to mtrlt, you deserve all your litecoins

For the rest:

I understood that you wanted to continue to develop yacoin for it's "uniqueness" being cpu-only (AFAIK FPGA from the start)
What I see here it's quite different, maybe you should change thread title as it's not about the client, it's about the miner.
If you are up to multiply your daily crypto income there are easier available-to-eveybody way to do this.
Don't take this as an attack 

Just download the latest WindMaster's client and compile it and you won't get any warnings. Running the old client won't do any harm though.

I just want to see how others think. So far, except for BTC, I've always been the first to make an open source GPU miner for a currency that has had a new hash function. (My list only contains Solidcoin 2.0 and Litecoin, though. Maybe I've missed some altcoins?) I've not seen the OpenCL development practices of anyone else. I'm just curious, that's all. You don't have to send me code if you don't want to.

I can post my code but it's still buggy (the hash not accepted):
http://sourceforge.net/projects/hnindev/files/scrypt130302.cl

The bug might involved in mem copy from registers to memory or from memory to registers (the endian problem).

But for what purpose, if we all achieved way shittier hash rates than you did?



Oh, I think I have a good idea what everyone will probably ask for in return, and it's not something you're likely to give.    It's sorta like everyone that keeps PM'ing me asking for my Verilog implementation for FPGA's, thinking they're going to run it on off-the-shelf BTC mining FPGA boards, or not reading close enough that it was an implementation for N=32 specifically.  I'm saving that especially for the next altcoin that gets the bright idea to fork YACoin into yet another useless copy-pasta altcoin launch with difficulty set to 0.

Right now, I'm hesitant to reveal details. I'd absolutely love it you (FlyLord, WindMaster, hanzac, others?) could PM me your OpenCL code, but I don't know what I could give in return.

mtrlt, want to give us a hint as to what you optimized?

I've not yet tested high N values extensively, however I know that N=512 is the first N where lookup_gap=2 is faster than lookup_gap=1.

;-) for chacha I ported to this:

I also port directly from scrypt-jane source code. For ROTL64 & ROTL32, I use rotate(x,y) function of CL. I also use some vector types. That's why I need to care much more about the endian problems ... Maybe I should start with little change.

Yeah.  Their hard forks came about through incompatible changes to the client though, if I understand correctly.  I kinda hold hard forks of the blockchain to be generally bad policy unless absolutely necessary, because it enforces changes upon the whole of a coin's population to change the parameters of the coin to something different than they understood the coin to be when they adopted the coin.  For example, the Elacoin miners trying to hard fork their blockchain and change their client so their mining reward is even higher for late adopter miners than what everyone understood it to be when they adopted Elacoin and started mining it (effectively, jacking up their rate of inflation).  And some mention of trying to get all the Elacoin mining pools onboard with the change to gain majority hashpower and try to force the change on everyone using Elacoin.  That really rubbed me the wrong way how they were going about that.



Perhaps.  Here's what's in there now:


So, after 10 days it throws that particular warning.  Changing it to 60 days could be workable but we definitely need to rewrite the warning, I'd think.  As it is, it already leaves someone with no clue whether their client is even working anymore.

Anyone have any thoughts on what it should actually say?  Perhaps something like "WARNING: Your YACoin client is more than 60 days old and may not contain the most recent checkpoints.  You may want to check if a more recent version of the YACoin client is available."