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

Selling is forbidden at the moment, only buying 

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

I have not updated the original wallet.

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

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.

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.  



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.

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:


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?

That was my point about strDNSSeed.

Currently in Novacoin it is:


Bitcoin setup a condition for testnet and is:

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?



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.

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

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.

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.

when's the release of the windows client ?

I'd prefer to build the binaries on this end, if I'm attaching my name and reputation (what little I have, anyway) to the integrity of the binaries and posting MD5 hashes to claim that I'm aware the binaries accurately represent what's in the source.  Not that people should particularly trust binaries from any unknown third party anyway though (especially in the cryptocurrency community, and that includes trusting binaries from me) and should take the proper precautions by running them in a VM or sandbox, or building them from source themselves.  Still, even if binaries from me are not to be trusted, over time we may be able to build up a level of trust that binaries I've posted and given my "stamp of approval" are legit.  Maintaining tight control over binary production is probably important for building that trust over time.

After all, a huge amount of the early FUD issue surrounding YACoin was a false allegation that certain versions of the compiled Windows client contained a Bitcoin wallet stealer, with multiple shill accounts on bitcointalk all claiming their Bitcoins were stolen.  We need to implement whatever changes are practical to reduce the likelihood of similar FUD campaigns in the future.

Absolutely do hop in and start working out what changes are needed to get UPnP fixed up for Windows though.  We'll get the changes committed to the repository and tested, then we can move on to the next issue(s) on the list (BTW, bug/feature improvement list is now in the 2nd post in this thread).



Good point, signing with GPG keys may be a viable option.  Other trusted community members may not necessarily be able to vouch for the binaries being legit and untampered though, prior to a sufficient amount of trust in my fork of the YACoin client being established.

This thread is probably giving RMS a huge chubby... 

http://en.wikipedia.org/wiki/Free_and_open-source_software

Yes, I was an original supporter, actually, then the Dev, pumped, dumped and abondoned the coin. Once I saw this thread, I immediately purchased 1 BTC worth, at ~ 0.0003...And looks like it was the right choice, because the value has doubled.

+1

A close examination of the first few thousand blocks will be especially interesting.  It may or may not reveal how many YAC the original developer mined, depending whether he mined everything into one coinbase wallet address or not.  I think it's reasonable to believe the address the first block after the genesis block was mined to is likely to be part of pocopoco's mining operation or someone tipped off to the launch ahead of time.

With any of these alt coins going forward, they'll be only as good as the community behind them. It's still very early on in a crypto-currency world and imo there's going to be many coins that have different levels of value far above what they are today. The window to get big in these early stages won't last too long, but atm it's still open.
Some coins may come along and even overtake bitcoin. However unlikely, it's not impossible.

I too am invested in YAC and its future growth and adoption. Thank you Windmaster for taking this initiative!! For those wondering about N, like me, I did some code digging. As the announcement post said, N starts at 32. There is a function in main.cpp (GetNfactor) that takes in the current timestamp to calculate the "NFactor", which is eventually fed into the scrypt() function of the scrypt-jane library (which is a LIBRARY/IMPLEMENTATION, not a specific scrypt algorithm) and converted to N as such:


So basically, left bitshift 1 over by (Nfactor + 1).

Near GetNfactor back in main.cpp, the following is also defined:


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.

From N we can get the memory required for the hashing by looking at the following code out of scrypt-jane.c:

Given that SCRYPT_BLOCK_BYTES is defined as 64, and rfactor = 0 (as passed in), chunk_bytes = 64 * 1 * 2, or 128. So to get the memory in bytes required for a given Nval, just do Nval * 128. To get it in KB, just do Nval * 128 / 1024, or simply Nval / 8 (as a shortcut).

EDIT: See the next page for an improved python script I've created to calculate N and memory required for hashing

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).
EDIT: As I graphed it out 20 years...this approximation doesn't really hold that well...unless my python adaptation is incorrect.

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?

Does it really matter if the original dev never returns at this point though?  We've now got an active developer interested in maintaining things, and services (pools ect.) starting to pop up.  So what if the original dev cashed out and made a bundle at this point, thats just more coins out in the wild for others to buy up if desired.   Are we worried about btc because Satoshi isn't around?

Doesn't that worry you that the dev didn't have any long term goals for this coin?   To me that screams pump and dump, and he's likely already cashed out a handsome sum.  I know you farmed up a ton of these with your server farm on the first day and have a great interest in trying to see this thing through, but to an outsider it seems this coin is on life support right now.