[ANN][YAC] YACoin ongoing development - page 174.

ongle

newbie

Activity: 22

Merit: 0

Quote from: WindMaster on May 18, 2013, 12:27:29 PM

Quote from: ongle on May 18, 2013, 11:55:06 AM

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

Yeah, there's probably little point to the checkpoint age test remaining, unless we really want everyone needing to download a new version of the client periodically. I'll defeat the checkpoint age test and also add a more recent checkpoint to my version of the client today.

Cool. I could see its value in testing or experimental forks, to keep people from using it beyond its intended use, but we're taking YAC to the moon! Wink

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: ongle on May 18, 2013, 11:55:06 AM

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

Yeah, there's probably little point to the checkpoint age test remaining, unless we really want everyone needing to download a new version of the client periodically. I'll defeat the checkpoint age test and also add a more recent checkpoint to my version of the client today.

ongle

newbie

Activity: 22

Merit: 0

Quote from: ?? on ??

Quote from: yantis on May 18, 2013, 07:21:34 AM

Its worth noting the official windows client says "WARNING: Checkpoint is too old. Wait for block chain to download or notify developers"

As far as I understand the issue there, it could be fixed by adding hash of some recent block to checkpoints.cpp file at github and compiling new client.

Code:

    // Is the sync-checkpoint too old?
    bool IsSyncCheckpointTooOld(unsigned int nSeconds)
    {
        LOCK(cs_hashSyncCheckpoint);
        // sync-checkpoint should always be accepted block
        assert(mapBlockIndex.count(hashSyncCheckpoint));
        const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
        return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
    }

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

Dehumanizer

member

Activity: 77

Merit: 10

So the 15000 block hash stays there too? I'll try it but it should work with just 65000 as well, shouldn't it?

Dehumanizer

member

Activity: 77

Merit: 10

Quote from: ?? on ??

Quote from: Dehumanizer on May 18, 2013, 11:32:11 AM

I'm getting the "checkpoint is too old" with the WindMaster's client as well, I have tried to fix it in the checkpoints.cpp but it didn't help...

What you mean with "tried to fix it"? Post the code.

as you suggested, I replaced the checkpoint block 15000 with 65000, i.e. this

Code:

( 15000, uint256("0x00000082cab82d04354692fac3b83d19cbe3c3ab4b73610d0e73397545eb012e"))

with this

Code:

( 65000, uint256("0x00000000105c73cd00aa0ba024c6ccd88b738f18bc598f5113470b7491b3df6e"))

then recompiled the client (also tried to make clean before compiling)

Dehumanizer

member

Activity: 77

Merit: 10

I'm getting the "checkpoint is too old" with the WindMaster's client as well, I have tried to fix it in the checkpoints.cpp but it didn't help...

seleme

legendary

Activity: 2772

Merit: 1028

Duelbits.com

Yeah, it certainly stopped the rally but maybe it's not so bad thing, I bought few more Grin

and it didn't went to pump and dump stage like some other coins did what's good thing.

But it does hurt the image of the coin, I'd like to see it removed and if there's something that could be done with the code to make them do it I believe it should be one of the priorities.

procrypto

full member

Activity: 224

Merit: 100

Shitcoin Maximalist

Quote from: seleme on May 17, 2013, 08:50:57 PM

WindMaster, what can be done to make bter remove that stupid warning they have on yac on their site? I'm not tech person and don't have a clue about that but why was yac the only one to get it and s there something it could be done to give them a proof so they can remove it?

I'm sure in good time they will remove it, once we've all been here for a while without losing our wallets or having our bank accounts raided Roll Eyes

For now its probably helping suppress the price, which isn't necessarily a bad thing..

eule

hero member

Activity: 756

Merit: 501

Quote from: mtrlt on May 18, 2013, 07:26:04 AM

I also have a working YAC kernel for my own miner, Reaper.

Just want to know one thing: Do GPUs throw CPUs into the water?

Puycheval

member

Activity: 95

Merit: 10

Quote from: mtrlt on May 18, 2013, 07:26:04 AM

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

Do you have numbers to share with us ?

mtrlt

member

Activity: 104

Merit: 10

Quote from: WindMaster on May 17, 2013, 07:34:48 PM

Quote from: mtrlt on May 17, 2013, 06:22:56 PM

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal. Why would we want to cap the N increase before 512MB is reached? It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now. In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's. Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Huh, for some reason I thought N was going up far more rapidly than that. Forgive my bad memory. Anyway, starting N at 512MB memory usage would have resulted in people being able to mine at something like 20 H/s (not tested, only approximately calculated), but I guess it would have been plenty of speed. Verifying blocks would have taken quite a long time though and would have eaten some of your hashrate, but again, it'd probably have been fine.

Quote

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

yantis

member

Activity: 110

Merit: 11

Its worth noting the official windows client says "WARNING: Checkpoint is too old. Wait for block chain to download or notify developers"

dragon2nd

member

Activity: 94

Merit: 10

Quote from: WindMaster on May 18, 2013, 03:23:41 AM

Quote from: digger on May 17, 2013, 08:26:04 PM

How can I know when next N change?

i know N now is 6, when next?

BTW - If anyone needs to find out the current value of N and the N factor, my version of the YACoin client on github (link in first post of this thread) adds that information in the data reported by the getmininginfo RPC command:

Quote

yacoin@blah:~$ ./yacoind getmininginfo
{
   "blocks" : 65142,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 6.74541496,
   "errors" : "",
   "generate" : false,
   "genproclimit" : 8,
   "hashespersec" : 0,
   "pooledtx" : 0,
   "testnet" : false,
   "Nfactor" : 6,
   "N" : 128
}

How about adding network hashrate?

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: digger on May 17, 2013, 08:26:04 PM

How can I know when next N change?

i know N now is 6, when next?

BTW - If anyone needs to find out the current value of N and the N factor, my version of the YACoin client on github (link in first post of this thread) adds that information in the data reported by the getmininginfo RPC command:

Quote

yacoin@blah:~$ ./yacoind getmininginfo
{
   "blocks" : 65142,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 6.74541496,
   "errors" : "",
   "generate" : false,
   "genproclimit" : 8,
   "hashespersec" : 0,
   "pooledtx" : 0,
   "testnet" : false,
   "Nfactor" : 6,
   "N" : 128
}

seleme

legendary

Activity: 2772

Merit: 1028

Duelbits.com

WindMaster, what can be done to make bter remove that stupid warning they have on yac on their site? I'm not tech person and don't have a clue about that but why was yac the only one to get it and s there something it could be done to give them a proof so they can remove it?

I think that should be one of priorities for you guys that know a thing or two about tech stuff, it might have an effect for other exchanges to not add it too as well on people to invest more in it.

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: digger on May 17, 2013, 08:26:04 PM

How can I know when next N change?

Read back a page to find plenty of info and even some spreadsheets of N values over time prepared by rbdrbd. Or you can look at the function that actually decides the N factor, in main.cpp, called GetNfactor().

Quote

i know N now is 6, when next?

That's the N factor, not N. To go from N factor to the actual N, calculate it like so:
N = (1 << (Nfactor + 1));

digger

sr. member

Activity: 322

Merit: 250

good work.
come to mine Yacoin here http://yac.ltcoin.net

here need some hash.

How can I know when next N change?

i know N now is 6, when next?

yantis

member

Activity: 110

Merit: 11

Great stuff! Keep up the good work.

Puycheval

member

Activity: 95

Merit: 10

Great work going on here, long live the YAC !

I'm new to cryptocoins but I feel really interested and I'd like to help, a little.

First, I computed the N graph over time with Matlab from C code. I've found exactly the same changing days that rbdrbd found (in fact, I verified the first and the last (13/05/2030 !) ones)
Then I tried to understand why we have that ugly curve. I made the assumption that it had to be simple. The C code is strange but it's obviously an integer algorithm approximating a real function.
It could be the Moore's law for the first years, so let's try N=t² with t being time in seconds since The Beginning.
As you know, N=2^Nfactor+1 so we can derive Nfactor=2.log(t)/log(2)-1. I tried many tweaks and long story short, here are plots for Nfactor=f(days) and 2.5log(days) :

EDIT : So finally it would mean that N=2^{2.5log(days)+1} or N=2.days^2.5

So, what does that mean ? I don't know and I suppose I didn't find the original equation but we get the idea.

PS1 : sorry for the english, that's not my first language
PS2 : can someone tell me where the difficulty is hidden in the source code ?

WindMaster

sr. member

Activity: 347

Merit: 250

Quote from: mtrlt on May 17, 2013, 06:22:56 PM

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal. Why would we want to cap the N increase before 512MB is reached? It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now. In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's. Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Quote

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

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