[ANN][YAC] YACoin ongoing development

[WindMaster]

maybe it would be sufficient to just drop "unofficial client fork" from the topic, it might scare a lot of people

True.  That is now dropped from the topic title.

[1714247152]

1714247152

[1714247152]

1714247152

[1714247152]

1714247152

[ecliptic]

crossposting

This is a very bad idea.  You have just introduced another litecoin cgminer gpu catastrophe

I would not be surprised if people, maybe even many people independently, have forked and created their own cgminer in secret which is capable of utilizing GPUs, giving them several order of magnitude advantage over everyone else.

Actually, this is already happening. I've seen 3 people posting they have working opencl kernels (two of them had relatively low hashrates, the third one claims to be the dev of the Reaper litecoin gpu miner and has hashrates in the Mh/s range).

[bitdwarf]

"moneysupply" : 2826236

If anyone is GPU mining, they are definitely not moving much the total supply.

[WindMaster]

crossposting

This is a very bad idea.  You have just introduced another litecoin cgminer gpu catastrophe

I would not be surprised if people, maybe even many people independently, have forked and created their own cgminer in secret which is capable of utilizing GPUs, giving them several order of magnitude advantage over everyone else.

Actually, this is already happening. I've seen 3 people posting they have working opencl kernels (two of them had relatively low hashrates, the third one claims to be the dev of the Reaper litecoin gpu miner and has hashrates in the Mh/s range).

You're actually crossposting to a thread where this isn't particularly groundbreaking news.  This thread is where the information sairon posted came from, and I believe I'm one of the 3 people sairon refers to as having benchmarked a working OpenCL kernel (which had relatively low hash rates).  Recommend reading more than just the last page of this thread and the official YACoin thread, as this has been discussed to death already (in both threads).

[sairon]

Just found this, dunno what it means... Take a look at block #65950. Now look at its timestamp and comapre it with the previous and next blocks. The block #65951 actually references a block from the future (2 hours) as its predecessor. WTF?

Code:

blockNumber,time,target,avgTargetSinceLast,difficulty,hashesToWin,avgIntervalSinceLast,netHashPerSecond
65948,1368947791,4514804921008731308454430435778960213168305865242321266277686968320,4513641497971115828711486814529046024528909146303095102832514587060,5.971,25647196559,171,150022265
65949,1368947926,4516461674132362327428514198696163951811506256528911325690882686976,4514804921112633307813024314283998771971589842941187092551326050290,5.969,25637788514,135,189979234
65950,1368954783,4517581709949210843650566946274525742145464232015577932297087746048,4516461674301031541131425724681672434723711469088240722175479913075,5.967,25631432184,6857,3738922
65951,1368947984,4619111269461582367239859195192825077698022061568762349217099284480,4517581710069151063071590748558847984710411633611607164785871725281,5.836,25068045016,-6799,Infinity
65952,1368948016,4514350157542206014206452060506827664151792081795080735905296678912,4619111269483137401095330193924680793834345357377930282214297105835,5.972,25649780189,32,783376407
65953,1368948106,4513930746712654417744535608400726620712533786813703426975283019776,4514350157549266139778184631237032541778948367955566187930484179163,5.972,25652163432,90,284997558

http://yacexplorer.tk/chain/Yacoin/q/nethash/1/65940/65960

[eule]

netHashPerSecond : Infinity
YAC to the moon! 

[WindMaster]

Just found this, dunno what it means... Take a look at block #65950. Now look at its timestamp and comapre it with the previous and next blocks. The block #65951 actually references a block from the future (2 hours) as its predecessor. WTF?

Code:

blockNumber,time,target,avgTargetSinceLast,difficulty,hashesToWin,avgIntervalSinceLast,netHashPerSecond
65948,1368947791,4514804921008731308454430435778960213168305865242321266277686968320,4513641497971115828711486814529046024528909146303095102832514587060,5.971,25647196559,171,150022265
65949,1368947926,4516461674132362327428514198696163951811506256528911325690882686976,4514804921112633307813024314283998771971589842941187092551326050290,5.969,25637788514,135,189979234
65950,1368954783,4517581709949210843650566946274525742145464232015577932297087746048,4516461674301031541131425724681672434723711469088240722175479913075,5.967,25631432184,6857,3738922
65951,1368947984,4619111269461582367239859195192825077698022061568762349217099284480,4517581710069151063071590748558847984710411633611607164785871725281,5.836,25068045016,-6799,Infinity
65952,1368948016,4514350157542206014206452060506827664151792081795080735905296678912,4619111269483137401095330193924680793834345357377930282214297105835,5.972,25649780189,32,783376407
65953,1368948106,4513930746712654417744535608400726620712533786813703426975283019776,4514350157549266139778184631237032541778948367955566187930484179163,5.972,25652163432,90,284997558

http://yacexplorer.tk/chain/Yacoin/q/nethash/1/65940/65960

Unless I'm mistaken (and I could be, as I have not closely scrutinized that part of the code), the timestamp comes from the time on the computer yacoind is running on when that user successfully mines a block.  There aren't any validity checks to determine that the time on someone's computer is set correctly, I believe the timestamp goes into the block unchecked by anyone else (there isn't anything else to check it against anyway, unless NTP were incorporated into the client or something, rather than relying on the computer's time) and is there just for information purposes.  Unless I'm mistaken, the person who mined block 65950 may just have had their time set incorrectly.

[sairon]

Unless I'm mistaken (and I could be, as I have not closely scrutinized that part of the code), the timestamp comes from the time on the computer yacoind is running on when that user successfully mines a block.  There aren't any validity checks to determine that the time on someone's computer is set correctly, I believe the timestamp goes into the block unchecked by anyone else and is there just for information purposes.  Unless I'm mistaken, the person who mined block 65950 may just have had their time set incorrectly.

You're probably right, even https://en.bitcoin.it/wiki/Block_timestamp says just this:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

EDIT: But my graphs look ugly now
http://imgur.com/GA5YeBa

[hanzac]

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

EDIT: But my graphs look ugly now
http://imgur.com/GA5YeBa

If the node can access the "Network-adjusted time", why not using it directly as the block completion time? It doesn't make sense to use the single node's timestamp.

Moreover, I think from the block chain, we can only see the transaction completion time (the block is completed) but without the transaction open time? This information might be needed for the both party of the transaction to check for a time-critical transaction.

[sairon]

Difficulty will "think" it took much longer than 60 seconds to find that specific block so it will adjust result downward, a bit.

By 0.131 in this case. Seems like quite a bit when we're talking in numbers less than 6.

[hanzac]

Difficulty will "think" it took much longer than 60 seconds to find that specific block so it will adjust result downward, a bit.

By 0.131 in this case. Seems like quite a bit when we're talking in numbers less than 6.

It seems that the next block took the beneficial:
65953   2013-05-19 07:21:46   2   88.9   5.972   2792270.214184   7.0035   11.0751   29.3145%
65952   2013-05-19 07:20:16   1   18.56   5.972   2792251.664184   7.00252   11.074   29.3174%
65951   2013-05-19 07:19:44   1   18.63   5.836   2792233.104184   7.0022   11.0737   29.3185%
65950   2013-05-19 09:13:03   1   18.549999   5.967   2792214.474184   7.08094   11.1523   29.0875%
65949   2013-05-19 07:18:46   3   40.141702   5.969   2792195.924185   7.00162   11.073   29.3205%

[seleme]

Some people are indeed bloody creative 

[WindMaster]

Meanwhile, looks like difficulty has now dropped below 4, with still enough hash power that there's little likelihood we'll stall out forever(ish) in excessive difficulty land like certain other {alt|scam}coin launches.

./yacoind getmininginfo
{
    "blocks" : 67785,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 3.96142507,
    "errors" : "",
    "generate" : true,
    "genproclimit" : 8,
    "hashespersec" : 105300,
    "networkhashps" : 117643499,
    "pooledtx" : 0,
    "testnet" : false,
    "Nfactor" : 7,
    "N" : 256,
    "powreward" : 19.87000000
}

[WindMaster]

I have calculated the complete schedule of N changes for YACoin out to the last increment, N=30, occurring in the year 2421.  The table is posted in the YACoin technical data on the first page of this thread:
https://bitcointalk.org/index.php?topic=206577.msg2162620#msg2162620

I certainly have my own opinion about the way N will change over the coming centuries and how it compares with Moore's Law.  You guys can draw your own conclusions.

[tacotime]

YACoin Technical Data
(this post will contain information about the basic parameters of YACoin, including more information on the hashing algorithm which is *not* called scrypt-jane, timeframe for N increases, PoS details when they become known, etc)


The schedule of N changes for YACoin is:

Nfactor		N		Memory		UNIX Time		Date/Time in GMT
4		32		4kB		1367991200		Wed - 08 May 2013 - 05:33:20 GMT
5		64		8kB		1368515488		Tue - 14 May 2013 - 07:11:28 GMT
6		128		16kB		1368777632		Fri - 17 May 2013 - 08:00:32 GMT
7		256		32kB		1369039776		Mon - 20 May 2013 - 08:49:36 GMT
8		512		64kB		1369826208		Wed - 29 May 2013 - 11:16:48 GMT
9		1024		128kB		1370088352		Sat - 01 Jun 2013 - 12:05:52 GMT
10		2048		256kB		1372185504		Tue - 25 Jun 2013 - 18:38:24 GMT
11		4096		512kB		1373234080		Sun - 07 Jul 2013 - 21:54:40 GMT
12		8192		1MB		1376379808		Tue - 13 Aug 2013 - 07:43:28 GMT
13		16384		2MB		1380574112		Mon - 30 Sep 2013 - 20:48:32 GMT
14		32768		4MB		1384768416		Mon - 18 Nov 2013 - 09:53:36 GMT
15		65536		8MB		1401545632		Sat - 31 May 2014 - 14:13:52 GMT
16		131072		16MB		1409934240		Fri - 05 Sep 2014 - 16:24:00 GMT
17		262144		32MB		1435100064		Tue - 23 Jun 2015 - 22:54:24 GMT
18		524288		64MB		1468654496		Sat - 16 Jul 2016 - 07:34:56 GMT
19		1048576		128MB		1502208928		Tue - 08 Aug 2017 - 16:15:28 GMT
20		2097152		256MB		1602872224		Fri - 16 Oct 2020 - 18:17:04 GMT
21		4194304		512MB		1636426656		Tue - 09 Nov 2021 - 02:57:36 GMT
22		8388608		1GB		1904862112		Mon - 13 May 2030 - 00:21:52 GMT
23		16777216		2GB		2173297568		Sat - 13 Nov 2038 - 21:46:08 GMT
24		33554432		4GB		2441733024		Fri - 17 May 2047 - 19:10:24 GMT
25		67108864		8GB		3247039392		Tue - 22 Nov 2072 - 11:23:12 GMT
26		134217728		16GB		3515474848		Mon - 26 May 2081 - 08:47:28 GMT
27		268435456		32GB		5662958496		Sat - 14 Jun 2149 - 12:01:36 GMT
28		536870912		64GB		6736700320		Tue - 24 Jun 2183 - 01:38:40 GMT
29		1073741824		128GB		9957925792		Tue - 21 Jul 2285 - 18:29:52 GMT
30		2147483648		256GB		14252893088		Sat - 28 Aug 2421 - 00:58:08 GMT

N is calculated from Nfactor as follows:
N = 1 << ( Nfactor + 1 )

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had.

[cryptrol]

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had.

Can you elaborate ? Isn't difficulty supposed to adjust while hashpower goes down ?

[Sahtor]

Block reward is based on difficulty and it will increase in the near future. Ofcourse we're already in <20 reward state which I consider to be deflationary. I'd consider 2.8M money supply to be almost static. If reward rises back to 50 or even 90 then we'd be in inflationary times.

All this will even out when more people adopt YAC. More miners will produce higher difficulty and that will lower the reward again.

[WindMaster]

Solid, within a year hashes will go from MH/s to double digit H/s    Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had.

While I often agree with a number of the things you've said, I'm worried you're starting to exaggerate.  In the main YACoin thread, today you posted that anyone could've developed a GPU miner days in advance, yet only the original developer (and anyone he tipped off) could've been aware he was going to pull a surprise move and use a different hashing algorithm than anyone was expecting.  Changing from scrypt+salsa20/8+SHA256(1024,1,1) to scrypt+chacha20/8+Keccak512(N,1,1) did turn out to be significantly more than just a copy-paste exercise from the scrypt-jane library source, at least for anything that was going to go faster on GPU's than typical desktop CPU's.

In your comment above, I think your numbers are exaggerated a bit.  I just benchmarked with a Linux build of cpuminer and forced N to various values:

Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k).

For N=32 (at coin's launch), hash rate = 358.77 kH/sec
For N=256 (right now), hash rate = 119.25 kH/sec
For N=32768 (in one year), hash rate = 0.606 kH/sec

Both your upper bound (MH/sec) and lower bound (double digit H/sec) are off by an order of magnitude each in the typical CPU hashing performance scenario, so your statement is really off by 2 orders of magnitude overall.

I'm all for pointing out problems with a coin when it's justified.  As you know, on day 1 of the coin launch, I was right there alongside you posting about the probability that GPU implementation was very likely to be possible, and I also posted honest details about my server farm mining, Amazon AWS mining, FPGA implementation at N=32, and the results of my GPU implementation.  You did parade a lot of that info as evidence of premining in the first post of your Superfun Premining thread, even though I started mining a whopping 8.5 hours after launch and I seriously doubt anyone can accuse me of either premining or instamining.  That probably pissed off plenty of people that would like those things to have remained secret, but I believe transparency and honesty is the answer to developing trust and keeping everyone in-the-loop on technical matters.

I think I have yet to sugar-coat anything related to YACoin, however.  When people grill me on the hard questions about whether YACoin is GPU mining resistant at any particular value of N, even though I'm not the original developer and didn't choose the hashing algorithm or starting value of N, and apparently made myself the "YACoin lightning rod" by actually stepping up to improve problems with the code and make it a better coin rather than just complain about it, I'm still right there being perfectly honest and saying "maybe, maybe not, we don't know yet until we see the source code for some of those GPU implementations."  We've had one person post OpenCL source in this thread that was pretty close to a copy-paste from the scrypt-jane library with a few tweaks, and from my analysis, he did get fairly close to a working implementation, but once fixed, the hash rate isn't spectacular.  It's appearing that getting a working OpenCL implementation is not difficult (well, debugging anything on OpenCL is an "adventure"), but getting one that performs much better than CPU's actually does take a fairly good OpenCL skillset (i.e. if mtrlt's posted hash rate numbers are accurate, which they may well be since he was the developer of the Reaper scrypt GPU kernel that cgminer uses too, then he probably sets the mark for skillset needed to correctly optimize for decent hash rates).

So, anyway, when I see exaggerations that are off by 2 orders of magnitude, I'm afraid I'll have to call you out on it (as much as I respect you).  I'd prefer to see you discredit a coin with accurate info, not exaggerations.

[feeling2011]

[YaCoin] Help, I send yacoin to same address in about 22 minutes


The second transaction always: Unconfirmed (0 of 6 confirmations).

The second transaction ID:
Transaction ID: c5dbdf30ca01025970ff4f6da5c6650d121643d332f5102eb1d36b7a22643bf8

Can anyone help me?

thanks.

[hanzac]

...
I'm all for pointing out problems with a coin when it's justified.  As you know, on day 1 of the coin launch, I was right there alongside you posting about the probability that GPU implementation was very likely to be possible, and I also posted honest details about my server farm mining, Amazon AWS mining, FPGA implementation at N=32, and the results of my GPU implementation.  You did parade a lot of that info as evidence of premining in the first post of your Superfun Premining thread, even though I started mining a whopping 8.5 hours after launch and I seriously doubt anyone can accuse me of either premining or instamining.  That probably pissed off plenty of people that would like those things to have remained secret, but I believe transparency and honesty is the answer to developing trust and keeping everyone in-the-loop on technical matters.
...

TBH, I don't think transparency & honesty is the essence & key for trust. Do you imagine what if some one takes off all his clothes & pants and you then give your precious trust? This is silly and pity.