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

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.

Yeah, it's largely out of the original developer's hands, as the blockchain is "in the wild" now.  Short of releasing a closed-source client with incompatible changes and somehow convincing the community as a whole that shunning the open source approach to cryptocurrencies is somehow better, there aren't any changes pocopoco can make that invalidate any of our own efforts to improve the coin.

Having said that, I doubt improving the client much was a high priority for pocopoco.  Seriously, he didn't even take 30 seconds to grep the source for any remaining occurences of "NovaCoin" or "NVC" and correct them.

I think a better solution would be to make the maximum outbound connection count configurable, through the config file and command line options.  As Bitcoin Megastore pointed out, a blanket change to increase the maximum outbound connection count isn't universally ideal for many situations, particularly people behind older/slower NAT'ing routers that don't have many connection tracking slots.

Now that block rate is in the ~1 minute target range rather than 1-2 seconds, the number of outbound connections is quite a bit less critical to the issue of orphaned blocks.  It was extremely critical when blocks were being solved rapid-fire early on, but has become a lot less critical now.

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.

It's a client fork, not a reset.
..and it's just wierd to see you cry about not losing your YAC when you and kooke were really nasty to the early YAC community.

Please don't reset the coin. A lot of people, have sunk a lot of time, money and resources into mining it, I don't think people would be very happy, if all their coins, suddenly became completely worthless...I know I would be upset, to lose my investment

Difficulty scales supply to demand. You have to make a case for difficulty being too low for the near future demand (which doesn't seem the case IMHO), and in that case for the need of capping supply instead of just raising difficulty.

If demand raises healthily then two billion is fine. It's like one million wallets with 2,000 coins on average. Remember the final aim is to maximize demand, not to maximize the value per coin (it's not the same).

Good point. A hard limit should be set somewhere not in the Billion range though...