[ANN][YAC] YACoin ongoing development

[coke]

Hey guys, just wanted to let you know that I haven't forgotten about YAC, and I'm amazed at the work that is done here to actively support this coin.
Also I got a tiny bit of good news, the pushpoold changes I made are indeed working, my testpool just mined a block. After I cleaned up the code I will put up a repository on github.

As for the mmcfe frontend, I still have to wait for 520 confirmations to see if I didn't screw up and everything is working as it should.

Regards,
cK'

[evilscoop]

It's already being mined on GPU and has been likely for a while.  The OpenCL is still being optimized though.

proof, link ?

[dentldir]

Yeah.. But I'm stuck on the scrypt thingy (some other ppl to...)

Code:

{standard input}: Assembler messages:
{standard input}:23: Warning: .type pseudo-op used outside of .def/.endef ignore
d.
...

Still haven't found a fix for this..

This rabbit hole seems to go pretty deep.  (Unless there is a magic define I'm missing).

The error messages are because as 2.22 on Linux uses the ELF x86 assembly dialect and as 2.22 on mingw32 uses the PE/COFF assembly dialect.

In src/scrypt-jane/code/scrypt-jane-portable-x86.h, replace the macro definitions around line 170 for asm_naked_* through asm_gcc_end() with:

Code:

#if defined(WIN32)
        #define asm_naked_fn_proto(type, fn) extern type STDCALL fn
        #define asm_naked_fn(fn) ; __asm__ (".intel_syntax noprefix;\n.text\n.globl " #fn "\n    .def " #fn "; .scl   2; .align   32;\n.endef\n" #fn ":\n"
        #define asm_naked_fn_end(fn) );
        #define asm_gcc() __asm__ __volatile__(".intel_syntax noprefix;\n"
        #define asm_gcc_parms() ".att_syntax prefix;"
        #define asm_gcc_trashed() __asm__ __volatile__("" :::
        #define asm_gcc_end() );
#else
        #define asm_naked_fn_proto(type, fn) extern type STDCALL fn
        #define asm_naked_fn(fn) ; __asm__ (".intel_syntax noprefix;\n.text\n" asm_align16 GNU_ASL(fn)
        #define asm_naked_fn_end(fn) ".att_syntax prefix;\n.type  " #fn ",@funct
ion\n.size " #fn ",.-" #fn "\n" );
        #define asm_gcc() __asm__ __volatile__(".intel_syntax noprefix;\n"
        #define asm_gcc_parms() ".att_syntax prefix;"
        #define asm_gcc_trashed() __asm__ __volatile__("" :::
        #define asm_gcc_end() );
#endif

And that will get you further, but equally as stuck:

Code:

{standard input}: Assembler messages:
{standard input}:400: Error: no such instruction: `pushl %esi'
{standard input}:403: Error: no such instruction: `movl %eax,%esi'
{standard input}:404: Error: no such instruction: `movl %edx,%eax'
mingw32-make: *** [build/scrypt-jane.o] Error 1

Those line numbers are not very instructive on where or why these att syntax lines are not valid.

Hopefully, someone with more x86 assembly-fu can set all this straight.  I'm not particularly confident that my macro changes are 100% correct either.

[WindMaster]

And that will get you further, but equally as stuck:

Code:

{standard input}: Assembler messages:
{standard input}:400: Error: no such instruction: `pushl %esi'
{standard input}:403: Error: no such instruction: `movl %eax,%esi'
{standard input}:404: Error: no such instruction: `movl %edx,%eax'
mingw32-make: *** [build/scrypt-jane.o] Error 1

Those line numbers are not very instructive on where or why these att syntax lines are not valid.

Hmm, those instructions look like perfectly valid AT&T x86 assembly to me.  If I have a chance tomorrow or during the weekend, my assembly-fu may need to spring into action.

[tyrion70]

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

[evilscoop]

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...

[wesleyrbk]

When is the N increase?

[WindMaster]

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.

[evershawn]

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.

[mtrlt]

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?

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.

[Joe_Bauers]

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.

[WindMaster]

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.

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?

[Puycheval]

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 ?

[yantis]

Great stuff! Keep up the good work.

[digger]

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?

[WindMaster]

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().

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));

[seleme]

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]

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:

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
}

[dragon2nd]

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:

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?

[yantis]

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