Author

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

hero member
Activity: 802
Merit: 1003
GCVMMWH

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.
member
Activity: 104
Merit: 10
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.
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.
sr. member
Activity: 347
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...

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.
member
Activity: 106
Merit: 10
When is the N increase?
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...
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*..
sr. member
Activity: 347
Merit: 250
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.
sr. member
Activity: 333
Merit: 250
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.
sr. member
Activity: 350
Merit: 250
It's already being mined on GPU and has been likely for a while.  The OpenCL is still being optimized though.



proof, link Huh?
newbie
Activity: 35
Merit: 0
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'
member
Activity: 66
Merit: 10
It's already being mined on GPU and has been likely for a while.  The OpenCL is still being optimized though.

sr. member
Activity: 347
Merit: 250
static const int MAX_OUTBOUND_CONNECTIONS = 8; is old code and should really be changed for all forks.

yeah, I'm behind an overly-restrictive firewall, so I do this to all coins I use.

I just committed changes to the git repository to implement configurable maximum outbound connection count.  As per Bitcoin Megastore's comments, I have limited the range of the parameter so you can't set it to excessively small numbers.  Currently I have the lower limit that you can set this parameter to as 4, and the upper limit as 100.  Additionally, I implemented range limits for the maxconnections= parameter as well to prevent it from being set lower than 8 or higher than 1000.

Command line parameter:
-maxoutbound=N    (where N=maximum number of outbound connections, default of 8, range of 4-100)

Alternatively, set it in yacoin.conf as:
maxoutbound=N
sr. member
Activity: 347
Merit: 250
Thanks for the graphs. If I understood them correctly, there will be a period of time when using CGMiner as it is (no modifications) will allow YAC GPU mining (N=1024).

The hashing algorithm used in the OpenCL kernel for scrypt in cgminer has the wrong mixing and hash function to use it as-is.  Litecoin uses scrypt+salsa20/8(1024,1,1) and YAC uses scrypt+chacha20/8(N,1,1).  So, the mixing algorithm was changed to chacha, and the (intermediate) hash function was changed to SHA3 (Keccak).  Unmodified cgminer scrypt kernel won't work for YAC even at N=1024.  If it were just an issue of what N is, the value of N can be changed in the cgminer OpenCL scrypt kernel with just a couple tweaks (looking for all instances of 1024 in the OpenCL source gets you close).  I think that's what most people were expecting prior to the coin's launch, that it would be identical to Litecoin's scrypt, just with a different N, and I think a ton of people had already modified N in cgminer in anticipation.  I think the change to a completely different hash and mix caught everyone by surprise.

If someone modifies cgminer's OpenCL kernel in such a way that it would work at N=1024, it would actually work right now at N=64 too.  There's definitely a whole lot more to it, or else people would've claimed the bounty for a YAC cgminer within about 60 seconds!

I bet in June, there's going to be a bunch of people that try to fire up cgminer when N becomes 1024.  Half of them are going to think it's working if they're solo mining (thus not expecting to hit blocks often and not getting obvious rejected shares that would tip them off to a problem).  They'll never actually mine any blocks though with an unmodified cgminer (disclaimer: unless someone releases a modified cgminer between now and then, but then that wouldn't depend on N being 1024).
sr. member
Activity: 644
Merit: 250
I just want to say, Good job everyone working on this (especially WindMaster). I wish I could help in some way (I do promote YAC when I can in the newbie section).

I'm no good at programming, or code. But I can be dramatic, and on occasion funny:
https://bitcointalksearch.org/topic/new-asic-with-off-wdc-support-203342
https://bitcointalksearch.org/topic/coins-what-are-they-made-of-205499

If there's any thing I can do to help, let me know.

K.
sr. member
Activity: 462
Merit: 250
I ran the program out 20 years and have saved the graphed output to http://goo.gl/2XsaU

Could you take screenshot and upload it to Imgur or somewhere else then post it here?

Over the next 1 year:



Over the next 20 years:


sr. member
Activity: 347
Merit: 250
I ran the program out 20 years and have saved the graphed output to http://goo.gl/2XsaU

Could you take screenshot and upload it to Imgur or somewhere else then post it here?

+1

Additionally, I'd like to post a graph in one of my posts on the first page of this thread, which I reserved for storing technical data on the hashing algorithm, Nfactor++ increase schedule, etc..


Here's an improved version to generate values of N over a specified range I whipped up in Python:

...

The data this output produces is a bit different than what's produced by the initial VBA version. I trust this code over that (I don't know VBA very well at all). Please check the code over and let me know what you think. May be good to compare it against a plain old C++ version just in case the python datatypes are doing something different than C++ would.

First glance at the data looks better than the earlier VBA version.  On this one, the transition from N=64 to N=128 happens in approximately the right timeframe, while the earlier VBA version was off by a few days.
sr. member
Activity: 462
Merit: 250
Here's an improved version to generate values of N over a specified range I whipped up in Python:

Code:
import sys
import time
import datetime
import csv

minNfactor = 4
maxNfactor = 30
nChainStartTime = 1367991200

def GetNfactor(nTimestamp):
    l = 0
    if nTimestamp <= nChainStartTime:
        return 4

    s = nTimestamp - nChainStartTime
    while ((s >> 1) > 3):
        l += 1
        s >>= 1

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

    if n < 0: n = 0

    assert n <= 255
    return min(max(n, minNfactor), maxNfactor);

def GetN(nTimestamp):
    Nfactor = GetNfactor(nTimestamp)
    return (1 << (Nfactor + 1))


while True:
    numDaysOut = raw_input("Generate N for how many days out? (e.g. 365): ")
    try:
        numDaysOut = int(numDaysOut)
        assert numDaysOut >= 1
    except:
        print "Invalid value. Must be numeric."
        continue
    else: break

while True:
    quantization = raw_input("Output a value of N for each X second period (e.g. 86400 = 1 day period): ")
    try:
        quantization = int(quantization)
        assert quantization >= 1
    except:
        print "Invalid value. Must be numeric."
        continue
    else: break

#startTS = time.mktime(datetime.datetime.utcnow().timetuple())
startTS = nChainStartTime #may 8th 2013
endTS = int(startTS + (numDaysOut*86400))

# rows are datetime string, TS, N, KB (N/8)
with open('output.csv', 'wb') as csvfile:
    outWriter = csv.writer(csvfile)
    for ts in xrange(startTS, endTS, quantization):
        nVal = GetN(ts)
        outWriter.writerow([datetime.datetime.fromtimestamp(ts).strftime('%Y-%m-%d %H:%M:%S'), ts, nVal, nVal/8])

I ran the program out 20 years and have saved the graphed output to http://goo.gl/2XsaU

To run this program, make sure you have python downloaded and installed on your computer (python.org). Save the code above as yacCalcN.py, then, open up a command prompt and invoke it. You will be prompted for some data. For example:
Code:
# python yacCalcN.py 
Generate N for how many days out? (e.g. 365): 365
Output a value of N for each X second period (e.g. 86400 = 1 day period): 86400

.csv output will be saved to output.csv, which will be able to be opened in MS excel for charting/manipulation.

The data this output produces is a bit different than what's produced by the initial VBA version. I trust this code over that (I don't know VBA very well at all). Please check the code over and let me know what you think. May be good to compare it against a plain old C++ version just in case the python datatypes are doing something different than C++ would.
legendary
Activity: 934
Merit: 1000
Yeah.. But I'm stuck on the scrypt thingy (some other ppl to...)

Code:
src\scrypt-jane\/code/scrypt-jane-romix-basic.h: In function 'scrypt_romix_nop':

src\scrypt-jane\/code/scrypt-jane-romix-basic.h:8:37: warning: unused parameter
'blocks' [-Wunused-parameter]
src\scrypt-jane\/code/scrypt-jane-romix-basic.h:8:52: warning: unused parameter
'nblocks' [-Wunused-parameter]
src\scrypt-jane\/code/scrypt-jane-romix-basic.h: In function 'scrypt_romix_conve
rt_endian':
src\scrypt-jane\/code/scrypt-jane-romix-basic.h:13:48: warning: unused parameter
 'blocks' [-Wunused-parameter]
src\scrypt-jane\/code/scrypt-jane-romix-basic.h:13:63: warning: unused parameter
 'nblocks' [-Wunused-parameter]
In file included from src\scrypt-jane\scrypt-jane.c:13:0:
src\scrypt-jane\/code/scrypt-jane-test-vectors.h: At top level:
src\scrypt-jane\/code/scrypt-jane-test-vectors.h:9:2: warning: missing initializ
er [-Wmissing-field-initializers]
src\scrypt-jane\/code/scrypt-jane-test-vectors.h:9:2: warning: (near initializat
ion for 'post_settings[2].salt') [-Wmissing-field-initializers]
{standard input}: Assembler messages:
{standard input}:23: Warning: .type pseudo-op used outside of .def/.endef ignore
d.
{standard input}:23: Error: junk at end of line, first unrecognized character is
 `h'
{standard input}:24: Warning: .size pseudo-op used outside of .def/.endef ignore
d.
{standard input}:24: Error: junk at end of line, first unrecognized character is
 `h'
{standard input}:142: Warning: .type pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:142: Error: junk at end of line, first unrecognized character i
s `s'
{standard input}:143: Warning: .size pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:143: Error: junk at end of line, first unrecognized character i
s `s'
{standard input}:265: Warning: .type pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:265: Error: junk at end of line, first unrecognized character i
s `s'
{standard input}:266: Warning: .size pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:266: Error: junk at end of line, first unrecognized character i
s `s'
{standard input}:398: Warning: .type pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:398: Error: junk at end of line, first unrecognized character i
s `s'
{standard input}:399: Warning: .size pseudo-op used outside of .def/.endef ignor
ed.
{standard input}:399: Error: junk at end of line, first unrecognized character i
s `s'
mingw32-make: *** [build/scrypt-jane.o] Error 1

Still haven't found a fix for this..
sr. member
Activity: 347
Merit: 250
Let me volunteer for fixing the UPnP issue and recompiling QT client and normal .exe. I've succcesfully build a number of qt clients now for some altcoins the last few days. All with upnp support. I'll have to read up on how to push changes to git cuz i never done that before, I'll PM u windmaster if I get stuck there.

I expect it to be done tonight (i'm at gmt-1 i think)

Great initiative!

Out of curiosity, have you already checked into what was amiss on UPnP for Windows in the official client?  I have not yet dug in to see why it was disabled for pocopoco's Windows client build.  Was it just not enabled (built with USE_UPNP=- or USE_UPNP=0), or is the code broken?

EDIT - Oh, I see it:

makefile.mingw:

Quote
# Copyright (c) 2009-2010 Satoshi Nakamoto
# Distributed under the MIT/X11 software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.

USE_UPNP:=0
USE_IPV6:=1
Jump to: