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

I have an off topic question, and hopefully someone may be in the mood to enlighten me. 

What kind of work is better done on the vector units of CPU rather than the GPU, provided the GPU isn't too busy doing things like rendering? My first interest about this question came from gaming hardware, but then thought it may relate to people designing a coin for which GPU has less of an advantage in mining.

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

You need to address the problem with block reward with a hard fork as soon as possible, in my opinion.  You'll probably end up with a slightly more valuable coin if you relaunch it later forking from the litecoin code instead once the GPU miner has been released.

I just want to say that most common people also expect respect in the first place. Transparency and honesty are too much for them sometimes. For the GPU implementations also have this effect, if the community shows more respect for the software developers, they will give much more instead of hiding innovative things / creating copy-cats / gold rushes / etc.

You did right to tell the truth, but things are not just easy to expand.

I don't quite follow that analogy.  Are you suggesting it would be better if I sugar-coat everything and say there's no possibility GPU implementations exist?  I'm not sure that would do much to increase trust..  I'm fairly certain no one wants to see me naked either.  

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.

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

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.

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.

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

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://bitcointalksearch.org/topic/m.2162620

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.

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
}

Some people are indeed bloody creative 

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%

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

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.

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


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

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.

netHashPerSecond : Infinity
YAC to the moon! 

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?


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