[ANN][YAC] YACoin ongoing development

[Seth Otterstad]

Is TacoTime right about this?  Why are people saying GPU mining will become impossible in august?

Current GPU implementations stop working at Nfactor value due to be in august. IMHO it's unlikely that this can't be fixed. However, GPUs should be much slower by then, only slightly faster than a CPU (AFAIK).

EDIT: see https://bitcointalk.org/index.php?topic=206577.msg2162620#msg2162620

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

[sairon]

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

Well, the N factor increases memory requirements for computing a single hash (thus it's using more memory and memory bandwidth). Current GPUs will quickly run out-of-memory (or there's other GPU-specific constraint that prevents the code from running at higher N, dunno). However, it also affects CPUs really hard (around 40% hashrate decrease if I remember correctly).

[procrypto]

Apologies to WindMaster and the rest of the community, I haven't had enough time to dedicate to this as yet, as it happens to have coincided with ongoing drama and mayhem in my meatspace job. Personally still getting up to speed with cryptocurrencies in general (I'm a front end web developer by trade) so don't feel I can yet contribute a whole lot to core development yet, but I'm learning fast.

On #2, anyone have further thoughts on whether a third-party miner (cpuminer) should indeed be included in the main YACoin installer, or if that would be better divided into a 2nd, different installer?  Same for selecting which p2pools to sort of "endorse" as part of the installer, when we know that p2pools are going to be a fast-moving target and any that are selected might randomly disappear or misbehave in the future, causing basically broken shortcuts unless someone is constantly checking for new versions of the client installer.

On the first point, I'd rather it all be in a single installer. I think we should definitely aim to keep the whole process as simple as possible (i.e. one installer to run over two).

Agree with this, single installer would be far preferable for most users.

b. the script that launches the miner makes a web service call to a central service (on google appengine for example) that will feed back a "current" list of p2pool hostnames. From this, the command line arguments are constructed. Making such a web service would be trivial. The script could be created that a default, hardcoded list would be used if this webservice was down.

This seems like a great idea, updating the list of p2pools remotely would be much better than relying on a hardcoded list alone.

Guys, have you seen bitminter.com? Very neat pool.

Love this kind of interface, would be super user-friendly for the average desktop miner to operate.

[tacotime]

So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant?

Coblee's thread about GPU-mining and Litecoin:
https://bitcointalk.org/index.php?topic=64239.0

Well, the N factor increases memory requirements for computing a single hash (thus it's using more memory and memory bandwidth). Current GPUs will quickly run out-of-memory (or there's other GPU-specific constraint that prevents the code from running at higher N, dunno). However, it also affects CPUs really hard (around 40% hashrate decrease if I remember correctly).

Nah, all you have to do is increase the lookup gap (via the previously published TMTO solution for scrypt from cgminer/reaper) and then you can compute the same hashes with less memory.

There's a probably bug in mtrlt's current code that doesn't allow calculation above N=4096, but it's possible that this particular TMTO implementation is not really optimized well for the GPU and that in the future with some hacking we'll see the gap further widen.

The further up the N value you get, the greater dependence on memory access speeds you typically observe (or at least, I observed using scrypt-jane on a CPU).  I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

BLAKE is used as an entropy source to randomize memory access too, I wouldn't be surprised if you looked at accesses to the lookup table and found that they end up being less than random as well due to consistent ordering of some types of data in the block header (thus also diminishing the amount of memory required).  I think pooler observed this when he was writing his CPU miner.

[Joe_Bauers]

 I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

+1

There's no way to [proof] proof anything forever... Unless WM wants to spend the time/effort to constantly try to stay ahead of GPU implementations...

Personally, I don't see a reason why eventual mass GPU YACoin mining would do anything but strengthen YAC as it did for LTC. Besides, there are going to be "lots" of vid cards sitting around looking for something to do once ASIC's completely take over Bitcoin. 

[theprofileth]

I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed.

+1

There's no way to [proof] proof anything forever... Unless WM wants to spend the time/effort to constantly try to stay ahead of GPU implementations...

Personally, I don't see a reason why eventual mass GPU YACoin mining would do anything but strengthen YAC as it did for LTC. Besides, there are going to be "lots" of vid cards sitting around looking for something to do once ASIC's completely take over Bitcoin. 

I am actually going to have to disagree. GPU mining means fpga's and asics can still function and thus dominate which is why YAC must be sure to keep it self safe from things such as this. Furthermore, GPU mining would only increase the difficulty and make my small supply of coins even smaller 
No but really litecoin isn't that well off, sure it is better than YAC or most other alt coins but thats pretty much because it was first not because GPU mining has treated it well.
If need be while it would be painful I think that the N factor should be increased if gpu mining became a viable option lest people begin the process of pumping and dumping. If we want YAC to last we need to keep it CPU only. Because even if everyone is going slower it will at least be a network wide slowdown and hit everyone relatively evenly which is partly why the massive speed decreases arent that bad because it is only a speed decrease for the network and not just for you and these decreases help keep YAC slightly safer with each increment. What I think we need next TBH is a proper mining program with stratum support. That way we can capitalize on the hashrate we still have left and get better feedback and less stale shares.

[Seth Otterstad]

The whole point of trying to make a GPU-hard coin is to get a more even initial coin distribution than bitcoin/litecoin did.  The number of people with CPUs is way higher than the number with good GPUs.  There is no point to making a new alt-coin to change the mining algorithm if it doesn't promote a wider distribution by cutting out the GPU farmers.  The algorithm doesn't have to last forever; it only has to last a few years until ASICs are developed.  Litecoin lost its whole purpose when it was taken over by GPUs.  If we knew a way to assign an equal amount of coins to everyone on the planet in a decentralized way, we would do that, but that technology is decades away.  Distributing it to everyone with a CPU is way less fair, but it is still vastly superior to giving it to everyone with a GPU.

[Joe_Bauers]

What I think we need next TBH is a proper mining program with stratum support. That way we can capitalize on the hashrate we still have left and get better feedback and less stale shares.

I looked at this very briefly a few days ago and it looks like it could be adapted to YACoin if someone has time to spend a few hours on it    https://github.com/CryptoManiac/stratum-mining

[AGD]

What is the advantage of Stratum mining?

[hanzac]

AMD's next gen APU with HSA will be very interesting, the unified memory addressing can be the boost for the scrypt or even scrypt jane. In next year, we can try Kaveri.

[cycloid]

What is the advantage of Stratum mining?

More work is done on miners end resulting in less bandwidth needed for the pool server.

[WindMaster]

AMD's next gen APU with HSA will be very interesting, the unified memory addressing can be the boost for the scrypt or even scrypt jane. In next year, we can try Kaveri.

Note that scrypt-jane isn't a hashing algorithm, it's a generic scrypt library that supports many different variations of scrypt, including scrypt+salsa20/8 as used by Litecoin.  I've noticed quite a few people refer to the scrypt variant used by YAC as "scrypt-jane", but that's actually wrong.

[theprofileth]

Hmm someone should put a bounty up for proper software or better yet integration into cgminer (which is much more likely than BFGminer due to lukejr's view on alt coins)
I'd be willing to throw a couple coins in to get a bounty up. (by coins I mean both YAC and BTC)

[hanzac]

Note that scrypt-jane isn't a hashing algorithm, it's a generic scrypt library that supports many different variations of scrypt, including scrypt+salsa20/8 as used by Litecoin.  I've noticed quite a few people refer to the scrypt variant used by YAC as "scrypt-jane", but that's actually wrong.

So what's the name for it? We shall give it a name, scrypt-chacha?

[dragon2nd]

{
    "blocks" : 76185,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 1.48652633,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "hashespersec" : 150811,
    "networkhashps" : 89660601,
    "pooledtx" : 0,
    "testnet" : false,
    "Nfactor" : 8,
    "N" : 512,
    "powreward" : 23.40000000
}

I've noticed a huge increase in network hashrate. It is now 600x my own hashrate, while it was still 300x two days ago.

[sairon]

I've noticed a huge increase in network hashrate. It is now 600x my own hashrate, while it was still 300x two days ago.

The client sometimes reports garbage, take a look at these graphs, they're averaged over 144 blocks (10 blocks for 24h graphs).
Network hashrate actually decreased on the 29th due to the Nfactor change.
http://yacexplorer.tk/graphs.htm

[JahPowerBit]

I think it's very important to see YAC on sites like http://www.coinchoose.com/

I found this post with formula for BTC : https://bitcointalk.org/index.php?topic=63273.msg743237#msg743237

But i have no idea how we can integrate N in this formula.. someone have an idea ?

[sairon]

I think it's very important to see YAC on sites like http://www.coinchoose.com/

I found this post with formula for BTC : https://bitcointalk.org/index.php?topic=63273.msg743237#msg743237

But i have no idea how we can integrate N in this formula.. someone have an idea ?

You need a formula for the block reward, Nfactor affects only difficulty.

EDIT: from the source:

Code:

int64 GetProofOfWorkReward(unsigned int nBits)
{
    CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);
    CBigNum bnTargetLimit = bnProofOfWorkLimit;
    bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());

    // ppcoin: subsidy is cut in half every 64x multiply of difficulty
    // A reasonably continuous curve is used to avoid shock to market
    // (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
    //
    // Human readable form:
    //
    // nSubsidy = 100 / (diff ^ 1/6)
    CBigNum bnLowerBound = CENT;
    CBigNum bnUpperBound = bnSubsidyLimit;
    while (bnLowerBound + CENT <= bnUpperBound)
    {
        CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
        if (fDebug && GetBoolArg("-printcreation"))
            printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
        if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
            bnUpperBound = bnMidValue;
        else
            bnLowerBound = bnMidValue;
    }

    int64 nSubsidy = bnUpperBound.getuint64();
    nSubsidy = (nSubsidy / CENT) * CENT;
    if (fDebug && GetBoolArg("-printcreation"))
        printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);

    return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}

[Sahtor]

Suggestion for official Yacoin currency symbol Ɏ or U+024E   

Symbol: Ɏ
Unicode name: Latin Capital Letter Y with stroke
Code: U+024E
Decimal:

Code:

Ɏ

https://en.wikipedia.org/wiki/List_of_Unicode_characters
https://en.wikipedia.org/wiki/Unicode_input

[bitdwarf]

Sounds good. I don't think the Igorot people in the Philippines will mind. http://en.wikipedia.org/wiki/Y_with_stroke