[ANN][YAC] YACoin ongoing development

[WindMaster]

when's the release of the windows client ?

After enough meaningful improvements have been made to make it worthwhile for people to upgrade from the official client.  At this point the changes made so far are mostly cosmetic, renaming lingering NovaCoin / NVC references that pocopoco should've cleaned up originally.

[rbdrbd]

when's the release of the windows client ?

After enough meaningful improvements have been made to make it worthwhile for people to upgrade from the official client.  At this point the changes made so far are mostly cosmetic, renaming lingering NovaCoin / NVC references that pocopoco should've cleaned up originally.

Once we get a release I'll update the YaCoin information thread with the updated client info, if it looks like the reception in this thread is good. I'll keep the link to the old one around as well for reference.

[fishboy]

when's the release of the windows client ?

After enough meaningful improvements have been made to make it worthwhile for people to upgrade from the official client.  At this point the changes made so far are mostly cosmetic, renaming lingering NovaCoin / NVC references that pocopoco should've cleaned up originally.

Once we get a release I'll update the YaCoin information thread with the updated client info, if it looks like the reception in this thread is good. I'll keep the link to the old one around as well for reference.

windmaster, you should try to join the YAC forums so that you'd also be updated ... according to one of the admins there pocopoco is busy IRL at the moment

[WindMaster]

Another reason to leave the default at 8 (even if I make it configurable) is that not everyone is mining.  Miners probably want good connection count to increase the odds of winning the "race" when they solve a block.  People that just want to use the wallet aren't going to be (as) concerned about solved block propogation time.

There is a nasty attack if some node can't accept incoming connections and it is limited to 1 or few outgoing connections. If such node connects to rogue (enemy) node or few of
them, it won't be able to sync with legit blockchain until eventualy it starts dropping connections to rogue nodes and go lucky with picking some legit node out of the peers.dat file.

Indeed.  If I make the max outbound connection count configurable, I'll use 8 as the minimum setting as well as the default.  Then someone would have to modify the source themselves to get it down to 1, and if they do that, they're on their own anyway.  Anyone have a case for the minimum configurable outbound count (in the case of making this a config file and command line option) being a number other than 8?

Here I am asuming node actualy had some legit nodes in peers.dat prior to connecting to rogue node. In the case that node is run by user who just installed YAC, if such node connects
to rogue nodes only it would never sync with legit blockchain because rogue nodes would surely share only IPs of the other rogue nodes.

I seem to recall the client is set up to connect to a certain IRC channel on the Freenode servers to locate other peer IP's.  Now that there's enough people running YACoin nodes/clients, it may be hard for a rogue operator to poison the list of available peers unless someone disables IRC (irc=0).  I need to double-check that the IRC portion is currently working correctly for peer discovery.

Some attention to the seed nodes are probably in order to ensure someone starting up the client for the first time will still accomplish something if the IRC-based peer discovery method fails.  Current official client source doesn't have any seed nodes set.

[Joe_Bauers]

Another quick text edit that can be made is:

Change all instances of  "Enter a YaCoin address (e.g. 4Zo1ga6xuKuQ7JV7M9rGDoxdbYwV5zgQJ5)" to a YAC address [starts with Y]


Also in net.cpp

need to do something about  strDNSSeed

That was my point about strDNSSeed.

Currently in Novacoin it is:

Code:

static const char *strDNSSeed[][2] = {
    {"seed", "seed.ppcoin.net"},
    {"tnseed", "tnseed.ppcoin.net"},
};

Bitcoin setup a condition for testnet and is:

Code:

static const char *strMainNetDNSSeed[][2] = {
    {"bitcoin.sipa.be", "seed.bitcoin.sipa.be"},
    {"bluematt.me", "dnsseed.bluematt.me"},
    {"dashjr.org", "dnsseed.bitcoin.dashjr.org"},
    {"xf2.org", "bitseed.xf2.org"},
    {NULL, NULL}
};

[WindMaster]

Another quick text edit that can be made is:

Change all instances of  "Enter a YaCoin address (e.g. 4Zo1ga6xuKuQ7JV7M9rGDoxdbYwV5zgQJ5)" to a YAC address [starts with Y]


Also in net.cpp

need to do something about  strDNSSeed

That was my point about strDNSSeed.

Currently in Novacoin it is:

Code:

static const char *strDNSSeed[][2] = {
    {"seed", "seed.ppcoin.net"},
    {"tnseed", "tnseed.ppcoin.net"},
};

Yeah, looks like we do need to do something about strDNSSeed.  An earlier commit by pocopoco had a couple hard-coded IP's as seed nodes, then they were removed from the source when the coin was launched.  So right now, we have:

Code:

static const char *strDNSSeed[][2] = {
    //{"yacoin.org", "seed.novacoin.su"},
};

So, no seed nodes at all.  Now the question is what we should select for seed nodes.  The ideal scenario is that we have (at least) 2, operated long-term by two separate parties.  I may be willing to operate one seed node long-term.  Anyone else have a server that's going to be operating yacoind for the long-term that can be used as a seed node?

[WindMaster]

This means that with the starting Nfactor being 4, so min N = 1 << (4 + 1) = 32, and the max Nfactor would be 30, so max N = 1 << (30 + 1) = 2147483648.

I've taken some of the code out to VBA and have created an excel spreadsheet graphing N over the next 10 years. Download it at http://goo.gl/pQqkI

Please feel free to review the code and let me know if there are any errors, as well as using the spreadsheet for your own needs around YAC.

Thanks for working up a spreadsheet.  I haven't looked closely at the accuracy of the data, although I did note that it showed N=64 only for one day before jumping to N=128.  I haven't continued watching N since I stopped mining when N went to 64 (thus invalidating my FPGA implementation).  When I have a moment, I'll bring out the C code in GetNfactor() into a small standalone program to verify the timestamps for Nfactor++ events.  Your data is different than what pocopoco (or perhaps it was someone else, can't remember) posted a while back in the official YACoin thread for the time vs. Nfactor++ events, but that doesn't mean what pocopoco posted was correct either.  

Looking at the graphed data, it appears that N very roughly approximates Moore's law (with some step lengths being shorter than 18/24 months, and others being larger).

Assuming my data is correct, what is everyone's opinion of N's growth? Does it seem realistic to a) keep GPUs out and b) keep CPU mining feasible?

Offhand, for question (b), it appears from your data that CPU mining continues being feasible for quite a long time.  Your data shows 512MB needed to calculate a hash in the year 2023, and that's an amount of RAM that I think everyone probably has available today for hashing.  Disclaimer - I haven't double-checked that your data is correct.

On question (a), I doubt 512MB needed to hash is enough to exclude GPU's, especially a decade out.  It may be enough to keep GPU's from having a huge massive advantage over CPU's once both technologies start having to hit slow external RAM and not fast internal L1/L2 caches, but we won't know for sure until we see what the future holds for GPU development, amounts of RAM on GPU's (and thus how many simultaneous hashes can be calculated in parallel), whether GPU's start getting massive quantities of fast L1/L2 cache like CPU's, what the ratio of L1/L2 cache in CPU's vs. GPU's looks like in a decade, etc..  Probably too early to tell.  We also need to see some of the GPU implementations or adaptations of cgminer released so we can see what they're achieving for hash rates.  Unlike Litecoin, where (almost) everyone derived their OpenCL implementation from Reaper, for YACoin, I suspect there were multiple independent adaptations of cgminer that occurred with no direct contact between the people performing each implementation.  Too early to tell on that as well, or determine exactly how widespread GPU mining of YACoin actually was/is.

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.

[WindMaster]

Another quick text edit that can be made is:

Change all instances of  "Enter a YaCoin address (e.g. 4Zo1ga6xuKuQ7JV7M9rGDoxdbYwV5zgQJ5)" to a YAC address [starts with Y]

Roger that, adding that to the bug list in the 2nd post in the thread.  Thanks for the bug find!

EDIT - Merged Joe_Bauers git pull request fixing this bug.

[wesleyrbk]

I'm going all-in YAC because of this development.

[aikklond]

I sent 500 YAC from local wallet to BTER an hour ago and still 0 confirmations...

I have not updated the original wallet.

[seleme]

I sent 500 YAC from local wallet to BTER an hour ago and still 0 confirmations...

I have not updated the original wallet.

Selling is forbidden at the moment, only buying 

[WindMaster]

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:

# 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

[tyrion70]

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

[rbdrbd]

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.

[WindMaster]

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.

[rbdrbd]

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:

[Kruncha]

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://bitcointalk.org/index.php?topic=203342.0
https://bitcointalk.org/index.php?topic=205499

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

K.

[WindMaster]

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

[WindMaster]

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

[Thracky]

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