[ANN][YAC] YACoin ongoing development

[WindMaster]

TBH, I don't think transparency & honesty is the essence & key for trust. Do you imagine what if some one takes off all his clothes & pants and you then give your precious trust? This is silly and pity.

I don't quite follow that analogy.  Are you suggesting it would be better if I sugar-coat everything and say there's no possibility GPU implementations exist?  I'm not sure that would do much to increase trust..  I'm fairly certain no one wants to see me naked either.  

[hanzac]

I don't quite follow that analogy.  Are you suggesting it would be better if I sugar-coat everything and say there's no possibility GPU implementations exist?

I just want to say that most common people also expect respect in the first place. Transparency and honesty are too much for them sometimes. For the GPU implementations also have this effect, if the community shows more respect for the software developers, they will give much more instead of hiding innovative things / creating copy-cats / gold rushes / etc.

You did right to tell the truth, but things are not just easy to expand.

[tacotime]

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had.

While I often agree with a number of the things you've said, I'm worried you're starting to exaggerate.  In the main YACoin thread, today you posted that anyone could've developed a GPU miner days in advance, yet only the original developer (and anyone he tipped off) could've been aware he was going to pull a surprise move and use a different hashing algorithm than anyone was expecting.  Changing from scrypt+salsa20/8+SHA256(1024,1,1) to scrypt+chacha20/8+Keccak512(N,1,1) did turn out to be significantly more than just a copy-paste exercise from the scrypt-jane library source, at least for anything that was going to go faster on GPU's than typical desktop CPU's.

In your comment above, I think your numbers are exaggerated a bit.  I just benchmarked with a Linux build of cpuminer and forced N to various values:

Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k).

For N=32 (at coin's launch), hash rate = 358.77 kH/sec
For N=256 (right now), hash rate = 119.25 kH/sec
For N=32768 (in one year), hash rate = 0.606 kH/sec

So, anyway, when I see exaggerations that are off by 2 orders of magnitude, I'm afraid I'll have to call you out on it (as much as I respect you).  I'd prefer to see you discredit a coin with accurate info, not exaggerations.

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

You need to address the problem with block reward with a hard fork as soon as possible, in my opinion.  You'll probably end up with a slightly more valuable coin if you relaunch it later forking from the litecoin code instead once the GPU miner has been released.

[ilostcoins]

I have an off topic question, and hopefully someone may be in the mood to enlighten me. 

What kind of work is better done on the vector units of CPU rather than the GPU, provided the GPU isn't too busy doing things like rendering? My first interest about this question came from gaming hardware, but then thought it may relate to people designing a coin for which GPU has less of an advantage in mining.

[WindMaster]

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will

You were off by a pretty large amount at both ends of the numbers you said hash rate would traverse over the course of a year.  However, with a more thorough calculation:

Best interpretation (most favorable to you) of your statement is that hash rates go from 1MH/sec to 99.999 H/sec over the course of the first year, a decrease in speed of about 10000x.  My benchmark showed a decrease of speed over the course of the first year of 358.77kH/sec to 0.606kH/sec with one particular common server CPU, a decrease in speed of about 592x.

10000 vs 592.  Or we could calculate that as 10000 / 592 = 16.9 and call that a single order of magnitude (plus change).  A strict interpretation of Wikipedia's "order of magnitude" article would suggest that this is the correct way.  So, I concede that you were off by a bit more than an order of magnitude if we analyze the most favorable interpretation of your statement.

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized.

Was the scrypt-jane library available somewhere prior to September 13, 2012?  If so, I'd like to snag a copy of that earlier version you benchmarked with.  Which hashing algorithm in the scrypt-jane library was that benchmark performed with?

[mtrlt]

I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.

[smilez]

So people can GPU mine yacoin now?:O

[seleme]

pocopoco really made some kick ass coin, shame he used his alter ego for it and never looked back at it.

With all these copycats out there recently it's the only coin that took some time and skills to be made.

[smilez]

So who is pocopoco?

[seleme]

YaCoin creator

[smilez]

YaCoin creator

I know that, but you said he used his alter ego.

So pocopoco should be someone else.

[Joe_Bauers]

With all these copycats out there recently it's the only coin that took some time and skills to be made.

It's interesting and unique enough (as indicated by the speculation and debates it provides (such as those by WM and taco))  that I've kept an eye on it since day one. The only thing that the cookie cutter coins have provided is a point-and-shoot solution for the pump~dumpers. YAC has some substance, which - along with active development, should hopefully keep it viable for the long term.    

[seleme]

YaCoin creator

I know that, but you said he used his alter ego.

So pocopoco should be someone else.

I don't have a proof for that but I'm fairly sure he is some other guy. He is obviously very knowledgeable and I don't think he appeared just like that.

Damn, I guess WindMaster might have some other nick too

[Sunny King]

It's good that yacoin did not change the 1 week average window of ppcoin's adjustment. So the attack can only change difficulty by ~2.5% for the next block, which may or may not be attacker's block.

This is not an exploit specific to the continuous difficulty adjustment of ppcoin. In bitcoin style step adjustment, an attacker can manipulate the timestamp of the last block of an adjustment interval. If attacker manages to mine the last block of an adjustment interval, the entire next interval's difficulty could be lowered. That's why one should stay with a longer adjustment window.

Bitcoin has +/- 2 hours maximimum block time offset since ages. I think it does not really matter much if block time is valid or not for as long as miner who added such block to
blockchain stays under 50% of network hashpower. Difficulty calculation takes block times in equation but one or few screwed blocks can't screw the result much. If some miner
would have 50% or more of network hashpower he could ruin difficulty calculation but he could ruin many other things as well, including much more important stuff than difficulty.

But make no mistake, some miner or few of them are playing with YAC block times on purpose. By putting block time in the future, he wants to affect difficulty calculation in such
a way that resulting difficulty is lower than it should be. Difficulty will "think" it took much longer than 60 seconds to find that specific block so it will adjust result downward, a bit.

[wetroof]

why does n stay at 512 for only a few days?

7      256      32kB      1369039776      Mon - 20 May 2013 - 08:49:36 GMT
8      512      64kB      1369826208      Wed - 29 May 2013 - 11:16:48 GMT
9      1024      128kB   1370088352      Sat - 01 Jun 2013 - 12:05:52 GMT



I appreciate all the discussion in this thread. and specifically the posts by windmaster.

[WindMaster]

why does n stay at 512 for only a few days?

The actual code that calculates the Nfactor isn't a nice smooth progression, it combines a couple calculations together that each cause Nfactor to change on different intervals.  The actual code in main.cpp looks like this, if curious:

Code:

int64 nChainStartTime = 1367991200;

const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

unsigned char GetNfactor(int64 nTimestamp) {
    int l = 0;

    if (nTimestamp <= nChainStartTime)
        return 4;

    int64 s = nTimestamp - nChainStartTime;
    while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;
    }

    s &= 3;

    int n = (l * 170 + s * 25 - 2320) / 100;

    if (n < 0) n = 0;

    if (n > 255)
        printf( "GetNfactor(%lld) - something wrong(n == %d)\n", nTimestamp, n );

    unsigned char N = (unsigned char) n;
    //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfa

    return min(max(N, minNfactor), maxNfactor);
}

[rbdrbd]

I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.

Very interesting news. Might there be some additional optimizations that you could do to get it to output (perhaps like messing with the lookup gap or some other TMTO hacks?)

I'm wondering two things:
a) why do you think it stopped working at 8192 (physical GPU limitation with current gen GPUs, or more a limitation of the code that can be more easily overcome)?
b) does CPU mining still work at 8192 and beyond? (if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).

Thanks for your insightful work on the GPU miner around YAC.

[bitdwarf]

Since we are doing some Q & A, I've been wondering if an insane high N would (painfully try to) use swap memory.

[WindMaster]

b) does CPU mining still work at 8192 and beyond?

Benchmark and test run at N=32768 I ran and posted on the previous page to dispute TacoTime's claim hash rates will drop to double digits in a year:

Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k).

For N=32 (at coin's launch), hash rate = 358.77 kH/sec
For N=256 (right now), hash rate = 119.25 kH/sec
For N=32768 (in one year), hash rate = 0.606 kH/sec

(if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).

If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork.

[tacotime]

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will

You were off by a pretty large amount at both ends of the numbers you said hash rate would traverse over the course of a year.  However, with a more thorough calculation:

Best interpretation (most favorable to you) of your statement is that hash rates go from 1MH/sec to 99.999 H/sec over the course of the first year, a decrease in speed of about 10000x.  My benchmark showed a decrease of speed over the course of the first year of 358.77kH/sec to 0.606kH/sec with one particular common server CPU, a decrease in speed of about 592x.

10000 vs 592.  Or we could calculate that as 10000 / 592 = 16.9 and call that a single order of magnitude (plus change).  A strict interpretation of Wikipedia's "order of magnitude" article would suggest that this is the correct way.  So, I concede that you were off by a bit more than an order of magnitude if we analyze the most favorable interpretation of your statement.

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized.

Was the scrypt-jane library available somewhere prior to September 13, 2012?  If so, I'd like to snag a copy of that earlier version you benchmarked with.  Which hashing algorithm in the scrypt-jane library was that benchmark performed with?

You're a feisty one.  You're correct on the date, it was during the memcoin thread which was apparently November of last year, so I guess only six months old.  Guess my memory slipped, but things move quickly these days.

If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork.

It works fine above that, I've used it beyond 32768 (see that thread).