[ANN][YAC] YACoin ongoing development

[digger]

seems yac has some other bugs!

[digger]

what's the max coins for YAC?

unlimited?

[procrypto]

what's the max coins for YAC?

unlimited?

If it's unchanged from Novacoin, there is a 2 billion cap written into the code, but this was never supposed to be a hard and fast limit or rule, and we'd probably never get there even if it was.

[Joe_Bauers]

what's the max coins for YAC?

unlimited?

It should be less than 500 Million in my opinion.

[Joe_Bauers]

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

[bitdwarf]

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

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

[Joe_Bauers]

That's an interesting point. Come on, let's get into character

[Hydroponica]

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

[R_Lem]

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

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.

[WindMaster]

I also recompiled my version to change

static const int MAX_OUTBOUND_CONNECTIONS = 8;

to

static const int MAX_OUTBOUND_CONNECTIONS = 200;

which seems to mitigate any UPNP issues.

static const int MAX_OUTBOUND_CONNECTIONS = 8; is old code and should really be changed for all forks.

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.

[WindMaster]

nope all fair points...
My issue was one that if the orig dev comes back, he may change something and make all your work go to crap....

Majority of hashpower and service providers like exchanges win, not developers.

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.

[bitbitcoincoin]

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.

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.

[nearmiss]

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.

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?

[rbdrbd]

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:

Code:

N = (1 << (Nfactor + 1));

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

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

Code:

const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

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:

Code:

r = (1 << rfactor);
chunk_bytes = SCRYPT_BLOCK_BYTES * r * 2;
V = scrypt_alloc((uint64_t)N * chunk_bytes);

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?

[R_Lem]

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.

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.

[WindMaster]

Delighted you have taken the bull by the horns, WindMaster. Don't have mad amounts of time today, but I'm definitely along for the ride and will offer all the hours I can. Tonight I hope to get the blockchain explorer up and running, as this feels like something we really need working now for the long-term credibility of YAC.

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

[Hydroponica]

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

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.

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.

[Joe_Bauers]

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

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

[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!

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

You can sign the binaries with a GPG key dedicated to this project and let some other trusted community members sign this keypair with their own GPG keys, thus making a web of trust around this project. Anonymity preserved, possible signature revocation should the private key ever get compromised, etc.

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.

[fishboy]

when's the release of the windows client ?