[ANN][YAC] YACoin ongoing development - page 174.

procrypto

full member

Activity: 224

Merit: 100

Shitcoin Maximalist

Quote from: seleme on May 17, 2013, 07:50:57 PM

WindMaster, what can be done to make bter remove that stupid warning they have on yac on their site? I'm not tech person and don't have a clue about that but why was yac the only one to get it and s there something it could be done to give them a proof so they can remove it?

I'm sure in good time they will remove it, once we've all been here for a while without losing our wallets or having our bank accounts raided Roll Eyes

For now its probably helping suppress the price, which isn't necessarily a bad thing..

eule

hero member

Activity: 756

Merit: 501

Quote from: mtrlt on May 18, 2013, 06:26:04 AM

I also have a working YAC kernel for my own miner, Reaper.

Just want to know one thing: Do GPUs throw CPUs into the water?

Puycheval

member

Activity: 95

Merit: 10

Quote from: mtrlt on May 18, 2013, 06:26:04 AM

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

Do you have numbers to share with us ?

mtrlt

member

Activity: 104

Merit: 10

Quote from: WindMaster on May 17, 2013, 06:34:48 PM

Quote from: mtrlt on May 17, 2013, 05:22:56 PM

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal. Why would we want to cap the N increase before 512MB is reached? It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now. In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's. Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Huh, for some reason I thought N was going up far more rapidly than that. Forgive my bad memory. Anyway, starting N at 512MB memory usage would have resulted in people being able to mine at something like 20 H/s (not tested, only approximately calculated), but I guess it would have been plenty of speed. Verifying blocks would have taken quite a long time though and would have eaten some of your hashrate, but again, it'd probably have been fine.

Quote

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

yantis

member

Activity: 110

Merit: 11

Its worth noting the official windows client says "WARNING: Checkpoint is too old. Wait for block chain to download or notify developers"

dragon2nd

member

Activity: 94

Merit: 10

Quote from: WindMaster on May 18, 2013, 02:23:41 AM

Quote from: digger on May 17, 2013, 07:26:04 PM

How can I know when next N change?

i know N now is 6, when next?

BTW - If anyone needs to find out the current value of N and the N factor, my version of the YACoin client on github (link in first post of this thread) adds that information in the data reported by the getmininginfo RPC command:

Quote

yacoin@blah:~$ ./yacoind getmininginfo
{
   "blocks" : 65142,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 6.74541496,
   "errors" : "",
   "generate" : false,
   "genproclimit" : 8,
   "hashespersec" : 0,
   "pooledtx" : 0,
   "testnet" : false,
   "Nfactor" : 6,
   "N" : 128
}

How about adding network hashrate?

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: digger on May 17, 2013, 07:26:04 PM

How can I know when next N change?

i know N now is 6, when next?

BTW - If anyone needs to find out the current value of N and the N factor, my version of the YACoin client on github (link in first post of this thread) adds that information in the data reported by the getmininginfo RPC command:

Quote

yacoin@blah:~$ ./yacoind getmininginfo
{
   "blocks" : 65142,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 6.74541496,
   "errors" : "",
   "generate" : false,
   "genproclimit" : 8,
   "hashespersec" : 0,
   "pooledtx" : 0,
   "testnet" : false,
   "Nfactor" : 6,
   "N" : 128
}

seleme

legendary

Activity: 2772

Merit: 1028

Duelbits.com

WindMaster, what can be done to make bter remove that stupid warning they have on yac on their site? I'm not tech person and don't have a clue about that but why was yac the only one to get it and s there something it could be done to give them a proof so they can remove it?

I think that should be one of priorities for you guys that know a thing or two about tech stuff, it might have an effect for other exchanges to not add it too as well on people to invest more in it.

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: digger on May 17, 2013, 07:26:04 PM

How can I know when next N change?

Read back a page to find plenty of info and even some spreadsheets of N values over time prepared by rbdrbd. Or you can look at the function that actually decides the N factor, in main.cpp, called GetNfactor().

Quote

i know N now is 6, when next?

That's the N factor, not N. To go from N factor to the actual N, calculate it like so:
N = (1 << (Nfactor + 1));

digger

sr. member

Activity: 322

Merit: 250

good work.
come to mine Yacoin here http://yac.ltcoin.net

here need some hash.

How can I know when next N change?

i know N now is 6, when next?

yantis

member

Activity: 110

Merit: 11

Great stuff! Keep up the good work.

Puycheval

member

Activity: 95

Merit: 10

Great work going on here, long live the YAC !

I'm new to cryptocoins but I feel really interested and I'd like to help, a little.

First, I computed the N graph over time with Matlab from C code. I've found exactly the same changing days that rbdrbd found (in fact, I verified the first and the last (13/05/2030 !) ones)
Then I tried to understand why we have that ugly curve. I made the assumption that it had to be simple. The C code is strange but it's obviously an integer algorithm approximating a real function.
It could be the Moore's law for the first years, so let's try N=t² with t being time in seconds since The Beginning.
As you know, N=2^Nfactor+1 so we can derive Nfactor=2.log(t)/log(2)-1. I tried many tweaks and long story short, here are plots for Nfactor=f(days) and 2.5log(days) :

EDIT : So finally it would mean that N=2^{2.5log(days)+1} or N=2.days^2.5

So, what does that mean ? I don't know and I suppose I didn't find the original equation but we get the idea.

PS1 : sorry for the english, that's not my first language
PS2 : can someone tell me where the difficulty is hidden in the source code ?

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: mtrlt on May 17, 2013, 05:22:56 PM

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal. Why would we want to cap the N increase before 512MB is reached? It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now. In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's. Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Quote

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Joe_Bauers

hero member

Activity: 802

Merit: 1003

GCVMMWH

Quote from: mtrlt on May 17, 2013, 05:22:56 PM

The possibility also exists that other technologies other than CPU and GPU options come into existence and widespread application during that timeframe that we can't yet anticipate, or that someone could identify a TMTO shortcut in scrypt+chacha20/8, as happened with the TMTO shortcut for scrypt+salsa20/8 that made GPU's practical for calculating Litecoin hashes.

That's why it is so important what WM is doing. With active development, things like this can be mitigated rather than the alternative.

mtrlt

member

Activity: 104

Merit: 10

Quote from: WindMaster on May 16, 2013, 01:17:13 PM

On question (a), I doubt 512MB needed to hash is enough to exclude GPU's, especially a decade out

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Quote

The possibility also exists that other technologies other than CPU and GPU options come into existence and widespread application during that timeframe that we can't yet anticipate, or that someone could identify a TMTO shortcut in scrypt+chacha20/8, as happened with the TMTO shortcut for scrypt+salsa20/8 that made GPU's practical for calculating Litecoin hashes.

The same TMTO that works for LTC, works for YAC.

evershawn

sr. member

Activity: 308

Merit: 250

Vod is a liar

YAC4EVER! It's a great coin, there are naysayers for every alt coin (a lot of times the same persons).

YAC will be at .02 soon, it's on the way.

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: evilscoop on May 17, 2013, 08:01:10 AM

is yac client meant to be connecting to irc...
Im sat in the chatroom with a load of clients

I thought the old bootstrap stuff was stopped...

Yes, the client uses IRC to locate other peers. There aren't any seed nodes, so this is currently the only way the client finds other peer the first time the client is started (and thus does not yet have a local database of peers). Perhaps when we have a sufficient number of seed nodes operated in the long-term by independent parties, this can change (maybe). Note that all the other altcoins are still using IRC to bootstrap the process of initially finding peers even if they have seed nodes hard-coded in the client. I haven't checked the most recent 0.9.x Bitcoin clients to see if Bitcoin still uses IRC as well.

wesleyrbk

member

Activity: 106

Merit: 10

When is the N increase?

evilscoop

sr. member

Activity: 350

Merit: 250

is yac client meant to be connecting to irc...
Im sat in the chatroom with a load of clients

I thought the old bootstrap stuff was stopped...

tyrion70

legendary

Activity: 934

Merit: 1000

I'm going to try to compile it with mingw on my linux machine instead.. If you can't beat them... *sigh*..

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