Hey, I'm checking in here with updates...
I've momentarily parked getting re-acquainted with C++ -- the text mentioned earlier includes material up to the most recent C++14 standard -- in order to focus on getting more in-depth practical knowledge with the Linux distro I'm using (which is necessary and co-requisite). One of the ROI-coin devs (Gary Hobson) was suggesting the most useful task at-the-moment is to learn to compile Windows wallets from source (this seems to be addressed in this link [
https://bitcointalk.org/index.php?topic=1080289.0 ] that Gyman posted in Cryptohub's chat. This'll probably require the use of some virtual machine to test the code on systems I have available now or near-term using different Windows versions...
perhaps some people actually running Windows as their usual OS will be roped into testing when the appropriate stage is reached (Hyperjacked??). I'm planning to get conversant with VMware, VirtualBox and Vagrant. Essentially, I'm working on needed homework.
In the long-run, I think we want to make CROC more streamlined than simply changing MAX_BLOCK_SIZE's value from 20000000 to 750000 (line 34 in main.h
https://github.com/RangaBoom/CrocodileCash/blob/master/src/main.h ), having people update their wallet, and hoping that solves the heavy-CPU usage.
A couple weeks back I was going through Peercoin's threads (the pre-announce and their current thread) and encountered this message [
https://bitcointalk.org/index.php?topic=101820.msg1122256#msg1122256 ] where, early-on, they goofed and didn't change the pchmessage parameter so that transactions weren't properly being distinguished between BTC and PPC. I bounced this off the ROI-coin devs and one of them referenced the same situation having happened to Feathercoin (here):
https://github.com/FeatherCoin/Feathercoin/issues/7 . This will be among the details to look at when we get closer to making this thing happen and effective/not-sloppily done.
To quote a message that Gary wrote: "pchMessageStart is not the only thing you need to modify , have a look at barterdex , where people have to add their coin , the info they need to supply for it, i ll get you an example
Checkpoints are not that important anymore despite popular believe… many think its a thing of the past.
Examples of what coins supply to get listed on a centralized exchange ( this one is BarterDex )
{“coin”:“LTC”, “name”:“litecoin”, “rpcport”:9332, “pubtype”:48, “p2shtype”:5, “wiftype”:176, “txfee”:100000 }
{“coin”:“DGB”,“name”:“digibyte”,“rpcport”:14022,“pubtype”:30,“p2shtype”:5,“wiftype”:128,“txfee”:100000}
{“coin”:“ROI”,“name”:“roicoin”,“confpath”:“USERHOME/.ROIcoin/ROIcoin.conf”,“rpcport”:3376,“pubtype”:60,“p2shtype”:122,“wiftype”:168,“txfee”:10000} " (end quote)
Admittedly the "wiftype" and "pubtype" are nebulous constructs to me at the moment (and only the other day did I see a reference elsewhere to "p2shtype" in something crypto-derived ). My understanding is that the rpcport and txfee are chosen by the dev/dev-team (but obviously we want to establish a new port # that doesn't conflict with the old CROC or other chains that people are likely to be hosting/supporting).
I'm also putting a feeler out about possibly reinstating a DPOS-period for the forked coin ... the idea being to encourage present holders to move to the new chain with a coin-swap (so that they'll end up with a greater percentage of the new chain instead of having a "CROC-classic" contingent stringing along the old one -- numbering among the living-dead Yobit chains). The tentative values I'm kicking around are to make a premine not much more than 300,000 excess of the existing CROC at the moment of the fork.
These quantities aren't set in stone but the PoW and PoS blocks currently being kicked around are something along the lines of this:int64 GetProofOfWorkReward(unsigned int nBits)
{
int64_t nSubsidy = 0 * COIN;
if(pindexBest->nHeight+1 <= 1)
{ // Premine to permit coin-swap of Mk I CROC (excess to be used for airdrop or bounties)
nSubsidy = 3,200,000 * COIN;
}
else if(pindexBest->nHeight+1 >= 2 && pindexBest->nHeight+1 <= 4000)
{ // A shorter period of higher mining reward (to not inflate the coin supply too much)
nSubsidy = 15 * COIN;
}
else if(pindexBest->nHeight+1 >= 4001)
{
nSubsidy = 1 * COIN;
}
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfWorkReward() : create=%s nSubsidy=%"PRId64"\n", FormatMoney(nSubsidy).c_str(), nSubsidy);
return nSubsidy;
}
// ppcoin: miner's coin stake is rewarded based on coin age spent (coin-days)
int64 GetProofOfStakeReward(int64 nCoinAge)
{
int64_t nSubsidy = nCoinAge * COIN_YEAR_REWARD * 33 / (365 * 33 + 8 ); //default 12% yr
// Proof-of-Stake begins at block 1440 (again)
if(pindexBest->nHeight+1 >= 1440 && pindexBest->nHeight+1 <= 20160)
{
nSubsidy = 60 * COIN;
}
else if(pindexBest->nHeight+1 >= 20161 && pindexBest->nHeight+1 <= 40320)
{
nSubsidy = 45 * COIN;
}
else if(pindexBest->nHeight+1 >= 40321 && pindexBest->nHeight+1 <= 60480)
{
nSubsidy = 30 * COIN;
}
else if(pindexBest->nHeight+1 >= 60481 && pindexBest->nHeight+1 <= 80640)
{
nSubsidy = 15 * COIN;
}
else if(pindexBest->nHeight+1 >= 80641)
{
nSubsidy = nCoinAge * COIN_YEAR_REWARD * 33 / (365 * 33 + 8 ); //default 12% yr
}
if (fDebug && GetBoolArg("-printcreation"))
printf("GetProofOfStakeReward(): create=%s nCoinAge=%" PRI64d"\n", FormatMoney(nSubsidy).c_str(), nCoinAge);
return nSubsidy;
}
Finally, @ both Currypto and Hyperjacked I would like to ensure that you guys have _at least the stake or percentage of the net-chain that you had formerly_ (we will try to make you whole again if your wallets are defunct and not stake-able at the moment).
