Pages:
Author

Topic: [ANN][CSC] CasinoCoin - The Premiere Coin for Casino Gaming | Kimoto Enabled! - page 9. (Read 290872 times)

legendary
Activity: 849
Merit: 1050
CasinoCoin
I would just like to take a moment to thank "casinocoin" for his efforts and dedication to this coin. Without him I think we would be looking at a dead coin.
Cheers, and
Thankyou, it's been a wild ride but I don't plan on going anywhere soon!

The last thing I want to see is something not only myself, but others have put a lot of time into just fade away when it has potential to be something.
Going to make some changes to the code and post them here later, unfortunately I have no idea how to compile c++ anyone want to help here?
Like this correct: http://stackoverflow.com/questions/1154517/c-compiler-for-windows ?
Or if anyone has the skills to do this quickly and efficiently let me know!
We will also need the mac wallet to be compiled(i can prob do this, but had some troubles last time on mavericks)

Got to say it's nice to see such commitment from the devs after seeing so many scam coins fade away.

CasinoCoin is going.. Nowhere but up! Glad your still along for the ride as well, sorry I couldn't get to purchasing any coins.

BTW, if we're going to fork the code, anyone have any other changes that people feel they would want? Personally, I wouldn't mind seeing a better scheme for reducing the block reward. 1/2 every 3 years is a bit nuts. I'd almost like to see this decrease less and more frequently. ANybody want to weigh in?

Also, maybe consider adding an incremental delay based on time that introduces delays into communications with a client that has an older version number. Overtime, this could push older clients out of the network pretty effectively without completely dropping them.
before we push the new source these will be some things we talk about, what would a good value be for the reduce of block reward in your opinion?
Have you seen this done with any coins, it's very interesting and would be a great feature to eventually force people to update and get rid of the old clients
legendary
Activity: 1652
Merit: 1057
bigtimespaghetti.com
Got to say it's nice to see such commitment from the devs after seeing so many scam coins fade away.
legendary
Activity: 952
Merit: 1000
Good work here guys! We have new devs  Wink

legendary
Activity: 1862
Merit: 1002
BTW, if we're going to fork the code, anyone have any other changes that people feel they would want? Personally, I wouldn't mind seeing a better scheme for reducing the block reward. 1/2 every 3 years is a bit nuts. I'd almost like to see this decrease less and more frequently. ANybody want to weigh in?

Also, maybe consider adding an incremental delay based on time that introduces delays into communications with a client that has an older version number. Overtime, this could push older clients out of the network pretty effectively without completely dropping them.

legendary
Activity: 1862
Merit: 1002
I'm not sure if that fix actually works. Supposedly Potcoin implemented it and still got attacked with the same timewarp deal.

Some have said to look into Digishield but I don't know how good that is.
I'll do some research before changing any code as don't want to waste time, have you seen the darkcoin implementation? I'd love for you to help along with the transition as you've been here before me and know what's goin on better then I do!

Have a look at Orbitcoin's implementation, seems to function as it should without problems.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Darkcoin's insertion here;

https://github.com/dx11/darkcoin/blob/master/src/main.cpp#L1273
It looks as if digicoin, orbitcoin, or darkcoins implementation could all be used.
Should we have a quick vote on which route wed like to take.

As cartman mentioned I think digishield should be an easy but very effective update,
Is there any other features persons would like to see with the wallet/client?

Darkcoin's devs generally seem to write more professional code IMHO.
legendary
Activity: 1270
Merit: 1000
I would just like to take a moment to thank "casinocoin" for his efforts and dedication to this coin. Without him I think we would be looking at a dead coin.

I would send you some CSC but I think you have too much already Wink
legendary
Activity: 849
Merit: 1050
CasinoCoin
I'm not sure if that fix actually works. Supposedly Potcoin implemented it and still got attacked with the same timewarp deal.

Some have said to look into Digishield but I don't know how good that is.
I'll do some research before changing any code as don't want to waste time, have you seen the darkcoin implementation? I'd love for you to help along with the transition as you've been here before me and know what's goin on better then I do!

Have a look at Orbitcoin's implementation, seems to function as it should without problems.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Darkcoin's insertion here;

https://github.com/dx11/darkcoin/blob/master/src/main.cpp#L1273
It looks as if digicoin, orbitcoin, or darkcoins implementation could all be used.
Should we have a quick vote on which route wed like to take.

As cartman mentioned I think digishield should be an easy but very effective update,
Is there any other features persons would like to see with the wallet/client?
full member
Activity: 129
Merit: 102
I'm not sure if that fix actually works. Supposedly Potcoin implemented it and still got attacked with the same timewarp deal.

Some have said to look into Digishield but I don't know how good that is.
I'll do some research before changing any code as don't want to waste time, have you seen the darkcoin implementation? I'd love for you to help along with the transition as you've been here before me and know what's goin on better then I do!

Have a look at Orbitcoin's implementation, seems to function as it should without problems.

https://github.com/ghostlander/Orbitcoin/blob/1e417b40a65dc316037855b1d3db3b32165c80db/src/main.cpp#L1157

Darkcoin's insertion here;

https://github.com/dx11/darkcoin/blob/master/src/main.cpp#L1273
legendary
Activity: 849
Merit: 1050
CasinoCoin
I'm not sure if that fix actually works. Supposedly Potcoin implemented it and still got attacked with the same timewarp deal.

Some have said to look into Digishield but I don't know how good that is.
I'll do some research before changing any code as don't want to waste time, have you seen the darkcoin implementation? I'd love for you to help along with the transition as you've been here before me and know what's goin on better then I do!


For everyone's reference

The DigiShield code can be found here between lines 833 & 1007:

http://www.digibyte.co/digishield
https://github.com/digibyte/DigiByteProject/blob/master/src/main.cpp
legendary
Activity: 1270
Merit: 1000
I'm not sure if that fix actually works. Supposedly Potcoin implemented it and still got attacked with the same timewarp deal.

Some have said to look into Digishield but I don't know how good that is.
legendary
Activity: 849
Merit: 1050
CasinoCoin
Ive got the repo up @
I would add the code tonight, but as It would take some looking around and understanding I will save it for tomorrow.
If anyone would like to make the required changes, can see the post(s) below

PM me and I will add you to the REPO, Spakler, anyone else interested etc.
We will also need to compile the new wallet for each platform after making the required changes, no?
As well set up an initial dns seed with the blockchain?
All kind of new to me but im learning!
Let's get this fixed.

Anyone else like to help please post here: forums.casinocoin.org


KGW Fix;
https://bitcointalksearch.org/topic/regarding-auroracoin-tw-exploit-fix-included-552895

Expermintal, Not sure about this: https://bitcointalk.org/index.php?topic=552895.140


Let's get started with some new details.

Website: http://casinocoin.org (updates to be completed very soon)
social media: facebook, twitter, google+ posted soon when have confirmed sources.
forums: http://forums.casinocoin.org
reddit: http://www.reddit.com/r/casinocoins
repo:

All coin details will stay the same, besides some much needed updates to the KGW.
We might as well move this to CasinoCoin-qt v2.0 and get completely away from 1.x Version to help eliminate confusion.



legendary
Activity: 849
Merit: 1050
CasinoCoin
Still no fix.... ?
It looks like the chain may have forked itself.

We are working to get a new stable chain out but first need to get cryptsy, and all miners on board
Going to send out some pms tonight to pool owners etc
member
Activity: 60
Merit: 10
Going buy a ton of these coins!

Same here, it's a great buying opportunity at present.
hero member
Activity: 2310
Merit: 532
Enterapp Pre-Sale Live - bit.ly/3UrMCWI
newbie
Activity: 24
Merit: 0
Going buy a ton of these coins!
hero member
Activity: 2310
Merit: 532
Enterapp Pre-Sale Live - bit.ly/3UrMCWI
haha litebit already sold out of their stock of CSC. they had inventory the other day. it seems to already be getting action over there. This should get the coin moving...

We sold over 100k, but we stopped the selling due to wallet issues....
hero member
Activity: 1305
Merit: 511
May have found the attacker/Pool and it could be unintentional. Will keep everyone posted(im on mobile atm)

MegaMineros pool-
440126   48 left   tmack2   11/05 05:19:28   4.43   50.00    18,151   6,829   1,544   8.51
Blockchain-
Block   Approx Time   Transactions   Coins Transferred   Total Coins   Difficulty
440127   2014-05-10T22:21:50-07:00   2   100.00000000   21,669,235   0.935
- See more at: http://altexplorer.net/chain/CasinoCoin#sthash.LG8wsSnV.dpuf

That is not the case here  Wink. tmack2 has been mining at my pool for a long time and he has not been the cause neither has MegaMineros been the attacker. We did find the last block before the attack/exploit took place but i can see from log files that after block 440127 there simply have been no new blocks on the network and hashrate did not increase on our pool during that time.

@casinocoin, no news from transcoder? If he has disappeared the only way to save this coin is solving the exploit and fork the blockchain asap!
legendary
Activity: 1862
Merit: 1002
haha litebit already sold out of their stock of CSC. they had inventory the other day. it seems to already be getting action over there. This should get the coin moving...
legendary
Activity: 849
Merit: 1050
CasinoCoin
Please read afew pages back to see up to date info on whats going on. We understand it is the KGW Bug/Exploit.
but I will take a loot at the post you pointed me to, thanks!
"
Code:

// Bitcoin used 10-minute blocks; this uses six minute blocks.
static const int64_t nTargetSpacing = 6 * 60;  // seconds per block, nominal.
static const int64_t nFastInterval = nTargetSpacing * 0.95; // seconds per block desired when behind schedule
static const int64_t nSlowInterval = nTargetSpacing * 1.05; // seconds per block desired when ahead of schedule
static const int64_t nTimeZero = 1400000000; // nominal date at which this blockchain starts, since unix epoch


void avgRecentTimestamps(const CBlockIndex* pindexLast, int64_t *avgOf5, int64_t *avgOf7, int64_t *avgOf9, int64_t *avgOf17)
{
  int blockoffset = 0;
  int64_t oldblocktime;
  int64_t blocktime;

  *avgOf5 = *avgOf7 = *avgOf9 = *avgOf17 = 0;
  if (pindexLast)
    blocktime = pindexLast->GetBlockTime();
  else blocktime = 0;

  for (blockoffset = 0; blockoffset < 18; blockoffset++)
  {
    oldblocktime = blocktime;
    if (pindexLast)
    {
      pindexLast = pindexLast->pprev;
      blocktime = pindexLast->GetBlockTime();
    }
    else
    { // genesis block or previous
      blocktime -= nTargetSpacing;
    }
    // for each block, add interval.
    if (blockoffset <= 5) *avgOf5 += (oldblocktime - blocktime);
    if (blockoffset <= 7) *avgOf7 += (oldblocktime - blocktime);
    if (blockoffset <= 9) *avgOf9 += (oldblocktime - blocktime);
    *avgOf17 += (oldblocktime - blocktime);    
  }
  // now we have the sums of the block intervals. Division gets us the averages.
  *avgOf5 /= 5;
  *avgOf7 /= 7;
  *avgOf9 /= 9;
  *avgOf17 /= 17;
}



// This is a novel getnextwork algorithm.  It responds quickly to huge changes in hashing power, is immune to time warp
// attacks, and regulates the block rate to keep the block height close to the block height expected given the nominal
// block interval and the elapsed time.  How close the correspondence between block height and wall clock time is
// depends on how stable the hashing power has been.

unsigned int GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
    int64_t avgOf5;
    int64_t avgOf9;
    int64_t avgOf7;
    int64_t avgOf17;
    int64_t toofast;
    int64_t tooslow;
    int64_t difficultyfactor = 10000;
    int64_t now;
    int64_t BlockHeightTime;
    int64_t nIntervalDesired;

    unsigned int nProofOfWorkLimit = Params().ProofOfWorkLimit().GetCompact();

    if (pindexLast == NULL)
        // Genesis Block
        return nProofOfWorkLimit;

    
    if (TestNet())
    {
        // Special difficulty rule for testnet: If the new block's timestamp is more than 2* 10 minutes then allow
        // mining of a min-difficulty block.
        if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
           return nProofOfWorkLimit;
        else
        {
            // Return the last non-special-min-difficulty-rules-block
           const CBlockIndex* pindex = pindexLast;
           while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
               pindex = pindex->pprev;
           return pindex->nBits;
        }
    }

    // Regulate block times so as to remain synchronized in the long run with the actual time.  The first step is to
    // calculate what interval we want to use as our regulatory goal.  It depends on how far ahead of (or behind)
    // schedule we are.  If we're more than a day ahead or behind, we use the maximum (nSlowInterval) or minimum
    // (nFastInterval) values; otherwise we calculate a weighted average somewhere in between them.  The closer we are
    // to being exactly on schedule the closer our selected interval will be to our nominal interval (nTargetSpacing).

    now = pindexLast->GetBlockTime();
    BlockHeightTime = nTimeZero + pindexLast->nHeight * nTargetSpacing;
    
    if (now < BlockHeightTime + 86400 && now > BlockHeightTime )  // ahead of schedule by less than a day.
      nIntervalDesired = ((86400 - (now - BlockHeightTime)) * nTargetSpacing +  
(now - BlockHeightTime) * nFastInterval) / 86400;
    else if (now + 86400 > BlockHeightTime && now < BlockHeightTime)  // behind schedule by less than a day.
      nIntervalDesired = ((86400 - (BlockHeightTime - now)) * nTargetSpacing +
(BlockHeightTime - now) * nSlowInterval) / 86400;
    else if (now < BlockHeightTime) nIntervalDesired = nSlowInterval; // ahead by more than a day.
    else  nIntervalDesired = nFastInterval; // behind by more than a day.
    
    // find out what average intervals over last 5, 7, 9, and 17 blocks have been.
    avgRecentTimestamps(pindexLast, &avgOf5, &avgOf7, &avgOf9, &avgOf17);    



    // check for emergency adjustments. These are to bring the diff up or down FAST when a burst miner or multipool
    // jumps on or off.  Once they kick in they can adjust difficulty by a factor of nine or ten every ten blocks, and
    // they can kick in very rapidly after massive hash power jumps on or off.  The emergency speed-up adjustment uses
    // shorter intervals for quicker reaction times measured in blocks - which when it's needed will be longer in
    // minutes.

    toofast = (nIntervalDesired * 3) / 4;
    tooslow = (nIntervalDesired * 4) / 3;    

    if (avgOf7 < toofast && avgOf9 < toofast && avgOf17 < toofast)
    {  //emergency adjustment, slow down
      difficultyfactor *= 5;
      difficultyfactor /= 4;
    }
    else if (avgOf5 > tooslow && avgOf7 > tooslow && avgOf9 > tooslow)
    {  //emergency adjustment, speed up
      difficultyfactor *= 4;
      difficultyfactor /= 5;
    }

    // If no emergency adjustment, check for normal adjustment.
    else if ((avgOf7 > nIntervalDesired && avgOf9 > nIntervalDesired && avgOf17 > nIntervalDesired) ||
    (avgOf7 < nIntervalDesired && avgOf9 < nIntervalDesired && avgOf17 < nIntervalDesired))
    { // 3 averages too high or 3 too low.  Doesn't matter which. This will be executed occasionally on the basis of
      // random variation, even if the settings are perfect. It regulates one-fifth of the way to the calculated point.
      difficultyfactor *= (5 * nIntervalDesired);
      difficultyfactor /= (avgOf17 + (4 * nIntervalDesired));
    }

    // limit to doubling or halving.... though I'm pretty sure there are no realistic conditions where this will make a
    // difference.
    if (difficultyfactor > 20000) difficultyfactor = 20000;
    if (difficultyfactor < 5000) difficultyfactor = 5000;

    uint256 bnNew;
    uint256 bnOld;

    bnOld.SetCompact(pindexLast->nBits);

    if (difficultyfactor == 10000) // no adjustment
      return(bnOld.GetCompact());

    bnNew = bnOld * 10000;
    bnNew /= difficultyfactor;

    if (bnNew > Params().ProofOfWorkLimit())
      bnNew = Params().ProofOfWorkLimit();

    LogPrintf("GetNextWorkRequired RETARGET\n");
    LogPrintf("Actual time %d, Scheduled time for this block height = %d\n", now, BlockHeightTime );
    LogPrintf("Nominal block interval = %d, regulating on interval %d to get back to schedule.\n",
     nTargetSpacing, nIntervalDesired );
    LogPrintf("Avg intervals of last 5/9/17 blocks = %d / %d / %d.\n", nTargetSpacing, avgOf5, avgOf9, avgOf17);
    LogPrintf("Difficulty Before Adjustment: %08x  %s\n", pindexLast->nBits, bnOld.ToString());
    LogPrintf("Difficulty After Adjustment:  %08x  %s\n", bnNew.GetCompact(), bnNew.ToString());

    return bnNew.GetCompact();
}

"
full member
Activity: 129
Merit: 102
Pages:
Jump to: