Pages:
Author

Topic: [ANN] Announcing Galaxycoin - GLX, the new PoW/PoS coin, no premine! - page 28. (Read 100439 times)

full member
Activity: 322
Merit: 113
Sinbad Mixer: Mix Your BTC Quickly
Quick updates are very nice.
At block 742, we'll see how this goes past 750. Tongue
And... Client crash  at 750 :/
sr. member
Activity: 476
Merit: 250
version 1.1 released. Download links updated in OP. After block 750, it will revert back to ppcoin's diff retarget algorithm (still adjust each block). Hopefully this will fix the diff oscillation issue.

github source has not been updated ...

updated
sr. member
Activity: 476
Merit: 250
full member
Activity: 145
Merit: 100
version 1.1 released. Download links updated in OP. After block 750, it will revert back to ppcoin's diff retarget algorithm (still adjust each block). Hopefully this will fix the diff oscillation issue.

github?

Edit: thanks!
sr. member
Activity: 476
Merit: 250
version 1.1 released. Download links updated in OP. After block 750, it will revert back to ppcoin's diff retarget algorithm (still adjust each block). Hopefully this will fix the diff oscillation issue.

This is a hard-fork, please update the client before block 750.


does not work
sr. member
Activity: 476
Merit: 250
OK, so hard-fork at block 750, I put back the ppcoin algorithm for diff adjusting:

Quote
   if(pindexLast->nHeight < 750)
   {
      int blockstogoback = nTargetInterval;

      const CBlockIndex* pindexFirst = pindexLast;
      for (int i = 0; pindexFirst && i < blockstogoback; i++)
         pindexFirst = pindexFirst->pprev;
      assert(pindexFirst);

      // Limit adjustment step, this should be enough since it is continuous adjustment, max twice or half
      int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
      printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);

      if (nActualTimespan < nTargetTimespan/2)
         nActualTimespan = nTargetTimespan/2;
      if (nActualTimespan > nTargetTimespan*2)
         nActualTimespan = nTargetTimespan*2;

      // Retarget
      bnNew.SetCompact(pindexLast->nBits);
      bnNew *= nActualTimespan;
      bnNew /= nTargetTimespan;

      /// debug print
      // printf("GetNextWorkRequired RETARGET\n");
      printf("nHeight = %d, nTargetTimespan = %"PRI64d", nActualTimespan = %"PRI64d"\n", pindexLast->nHeight, nTargetTimespan, nActualTimespan);
      // printf("Before: %08x  %s\n", pindexLast->nBits, CBigNum().SetCompact(pindexLast->nBits).getuint256().ToString().c_str());
      // printf("After:  %08x  %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString().c_str());
   }
   else   // ppcoin algo
   {
      const CBlockIndex* pindexPrev = GetLastBlockIndex(pindexLast, fProofOfStake);
      const CBlockIndex* pindexPrevPrev = GetLastBlockIndex(pindexPrev->pprev, fProofOfStake);
      int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();

      bnNew.SetCompact(pindexPrev->nBits);
      int64 nTargetSpacing0 = fProofOfStake? nTargetSpacing : min(nTargetSpacingWorkMax, (int64) nTargetSpacing * (1 + pindexLast->nHeight - pindexPrev->nHeight));
      int64 nInterval = nTargetTimespan / nTargetSpacing0;
      bnNew *= ((nInterval - 1) * nTargetSpacing0 + nActualSpacing + nActualSpacing);
      bnNew /= ((nInterval + 1) * nTargetSpacing0);
   }

the ppcoin algo is used in several others, like bottlecaps and cosmoscoin, so it should have no problem. Again sorry guys for the roller-coaster mining, it was not intended  Embarrassed
full member
Activity: 126
Merit: 100
Yes, hard-fork is the way to go ...

Be careful to not put something that enable insta-mining ... if the diff variation is strongly limited from one block to the next and the hard-fork happens at a low diff, it will take a large number of blocks to stabilize to the correct value (causing insta-mining as we have seen with many alts)


At least the launch was fair in its own way ^^

(per-announce would have been better though)
full member
Activity: 196
Merit: 100
Sorry guys, this looks like a failed trial.

I think we have two options:

1. Hard-fork at say, block 800. I can revert back to PP-coin/Novacoin retarget algorithm (still each block).
2. Do nothing and let it die. In which case I'll lock this thread.

Let me know which you prefer.


I choose 1
full member
Activity: 322
Merit: 113
Sinbad Mixer: Mix Your BTC Quickly
Sorry guys, this looks like a failed trial.

I think we have two options:

1. Hard-fork at say, block 800. I can revert back to PP-coin/Novacoin retarget algorithm (still each block).
2. Do nothing and let it die. In which case I'll lock this thread.

Let me know which you prefer.

1 Sounds find. The retarget every block seems okay in theory, just not the massive difficulty swing it's currently getting (i.e. double/half per block). Just leads to nothing being mined for a while.... then suddenly block block block block block, back to nothing...

 Fixable though. Go for it Tongue
sr. member
Activity: 476
Merit: 250
Sorry guys, this looks like a failed trial.

I think we have two options:

1. Hard-fork at say, block 800. I can revert back to PP-coin/Novacoin retarget algorithm (still each block).
2. Do nothing and let it die. In which case I'll lock this thread.

Let me know which you prefer.
full member
Activity: 126
Merit: 100
If you restart it, the coin is dead

possible ... but could also just be a saying from someone owning some blocks already ^^

For the retarget, a weighted average would probably be better than the current one ...

Also for the pre-launch test, the oscillation should have been visible anyway ... Values would not have been that high, but relative amplitude must have been identical.

I have gotten like 2 total so far. I'm just saying, from all the last coins that restarted, you may as well just not start it again and let it die

well, in the current case, screwed re-target algorithm did not cause unreasonably high mining ... a hard-fork is possible and indeed recommended over a restart.
Unstable block duration such as now is not a problem from a mining point of view (over a long period, the average is correct)... When people start making transactions, it will really become a problem for the confirmation time.
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
If you restart it, the coin is dead

possible ... but could also just be a saying from someone owning some blocks already ^^

For the retarget, a weighted average would probably be better than the current one ...

Also for the pre-launch test, the oscillation should have been visible anyway ... Values would not have been that high, but relative amplitude must have been identical.

I have gotten like 2 total so far. I'm just saying, from all the last coins that restarted, you may as well just not start it again and let it die
full member
Activity: 126
Merit: 100
If you restart it, the coin is dead

possible ... but could also just be a saying from someone owning some blocks already ^^

For the retarget, a weighted average would probably be better than the current one ...

Also for the pre-launch test, the oscillation should have been visible anyway ... Values would not have been that high, but relative amplitude must have been identical.
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
If you restart it, the coin is dead
sr. member
Activity: 476
Merit: 250
it's tested, unfortunately we don't have that mining power to test sudden changes of big hashrates.

Yes the diff algorithm is not perfect, it does cause diff to oscillate, however the oscillation is damping, so hopefully it will stablize after the start-time big changes in the hashpower.
full member
Activity: 322
Merit: 113
Sinbad Mixer: Mix Your BTC Quickly
Hm, yeah. I think a relaunch with a tweaked retarget would be alright. Right now it's going from a cgminer diff of ~500 to a diff of ~69.4k in 40 seconds with 8 blocks found in that span.... it's a huge roller-coaster ride. Seems decent enough besides that, again.
full member
Activity: 126
Merit: 100
diff retarget is indeed screwed ... I'm wondering if this coin has even been tested before launch ...

diff goes back and forth from ~0.003 to 2.5 every ~20 blocks

Also, target block time (30s) is too short and will cause security problems and instability of the block-chain.
newbie
Activity: 59
Merit: 0
diff seem oscillate, maybe algorithm is not perfect. In any case only big fishes will get the blocks, small potatoes like myself will need a mining pool.
hero member
Activity: 1073
Merit: 666
need a pool to mine this, matching network hash rate immediately with the diff is too radical, now I think instamine may make some sense, lol Grin
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
$ ./galaxycoind.exe getmininginfo
{
    "blocks" : 612,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 1.51249740,
    "networkhashps" : 187208267,
    "errors" : "",
    "pooledtx" : 0,
    "stakepower" : 0,
    "testnet" : false
}

now is better. But looks like re-target based on the last 10 blocks still cause some oscillations... may need to average more to smooth out.

Nothing wrong with that
Pages:
Jump to: