If you have not downloaded the new client... DO SO NOW, PLEASE! Subsidy is halving in a few hours. See you on the other side!  bumping this |
|
|
|
I'm trying to download the blockchain, but it seems to be getting stuck at block 45407
getinfo output:
"version" : "v1.1.4.9-g0f2adcb-cgb",
"protocolversion" : 60006,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 45407,
"moneysupply" : 454060.29526200,
"connections" : 8,
When I exit cryptogenicbulliond and restart it to resume the download, I get the following error message:
"ryptogenicBullion: Error loading blkindex.dat" (The 'C' is omitted from the error).
I've deleted everything in .CryptogenicBullion except for my conf and wallet, but when I try to download the blockchain again it freezes around the same block.
Here's my conf:
rpcallowip=127.0.0.1
rpcconnect=127.0.0.1
rpcport=8395
daemon=1
server=1
gen=0
testnet=0
listen=1
addnode=46.150.89.173
addnode=70.98.114.229
addnode=76.102.71.50
addnode=143.238.65.108
addnode=76.10.153.119
addnode=97.89.174.206
addnode=69.85.86.195
Is anyone else having this problem too?
No, I don't have that problem. And I see you're using the updated client... First, here's my config file: rpcallowip=127.0.0.1 rpcconnect=127.0.0.1 rpcport=8395 p2pport=7695 daemon=1 server=1 gen=0 testnet=0 listen=0 maxconnections=100 addnode=46.150.89.173 addnode=70.98.114.229 addnode=76.102.71.50 addnode=143.238.65.108 addnode=76.10.153.119 addnode=97.89.174.206 addnode=69.85.86.195 And you already tried deleting peers.dat and blkindex.dat, so I don't know... Let me know if my config file helped at all. Maybe I'll think of something else. |
|
|
|
|
keep'em coming ladies and gents...looking good
|
|
|
|
No good for scrypt, primecoin should work.
Even 7020 version with 512KB of RAM? I bought that version a few days ago just for fun, mainly for Monte Carlo/Machine learning stuff, but I thought I'd give it a go for some scrypt mining. -Merc |
|
|
|
As requested:Enlarged C:  Inverted Colors:  love the concept but the image needs to be sharpened up imho, ice is sharp yeah, I think you're trying to go with the frost texture but it's just quite not working...how about a polished/shiny texture? Looking good so far! We have outsourced some of our logo/design work but more options is good! By the way, client update imminent. |
|
|
|
As requested:Enlarged C: Inverted Colors: love the concept but the image needs to be sharpened up imho, ice is sharp yeah, I think you're trying to go with the frost texture but it's just quite not working...how about a polished/shiny texture? Looking good so far! |
|
|
|
I was a little bored today, ended up messing around with photoshop & a modeling program. Came up with this:  I'm not sure if you're looking for a new logo, but if you are, I can fiddle a bit more when I've got some free time. Repost from other CGB thread. Can you make the C larger just a tad? You picked the right color, that's the main color of the CGB website in development. |
|
|
|
|
I posted above guys, block reward will half at block 55000 to give pool ops and exchanges, etc enough time to update client. But instead of block rewards halving again at block 100,000, it will have at 95000. So at the second halving of block rewards there will be 750K total coins just as with the previous halving schedule.
New fix:
55K blocks @ 10 = 550,000 (up to block 55,000)
40k blocks @ 5 = 200,000 (up to block 95,000)
750K total coins at block 95000
All is well that ends well...
|
|
|
|
// miner's coin base reward based on nBits
int64 GetProofOfWorkReward(unsigned int nHeight)
{
int64 nSubsidy = 0 * COIN;
if (nHeight > 0)
{
nSubsidy = 10 * COIN; // 500,000 coins
}
else if (nHeight > 50000)
{
nSubsidy = 5 * COIN; // 250,000 coins
}
else if (nHeight > 100000)
{
nSubsidy = 2.5 * COIN; // 125,000 coins
}
else if (nHeight > 150000)
{
nSubsidy = 1.25 * COIN; // 62,500 coins
}
else if (nHeight > 200000)
{
nSubsidy = 0.75 * COIN; // 37,500 coins
}
else if (nHeight > 250000)
{
nSubsidy = 0.375 * COIN; // 18,750 coins
}
else if (nHeight > 300000)
{
nSubsidy = 0.1875 * COIN; // 9,375 coins
}
else if (nHeight > 333334)
{
nSubsidy = 0.01 * COIN; // 5256 coins per year roughly 0.053% yearly inflation
}
return nSubsidy;
} That should be more like: // miner's coin base reward based on nBits
int64 GetProofOfWorkReward(unsigned int nHeight)
{
int64 nSubsidy = 0 * COIN;
if (nHeight > 0)
{
nSubsidy = 10 * COIN; // 500,000 coins
}
if (nHeight > 50000)
{
nSubsidy = 5 * COIN; // 250,000 coins
}
if (nHeight > 100000)
{
nSubsidy = 2.5 * COIN; // 125,000 coins
}
if (nHeight > 150000)
{
nSubsidy = 1.25 * COIN; // 62,500 coins
}
if (nHeight > 200000)
{
nSubsidy = 0.75 * COIN; // 37,500 coins
}
if (nHeight > 250000)
{
nSubsidy = 0.375 * COIN; // 18,750 coins
}
if (nHeight > 300000)
{
nSubsidy = 0.1875 * COIN; // 9,375 coins
}
if (nHeight > 333334)
{
nSubsidy = 0.01 * COIN; // 5256 coins per year roughly 0.053% yearly inflation
}
return nSubsidy;
} Using else if is what caused it not to hard fork with a reduced subsidy because the first condition is always going to be true so there is never going to be an else. Your code would work, but it's not good because you'll get a true then a true every time. Instead is better to have first if statement as less than 50,000...then next else if as less than 100,000, etc. |
|
|
|
|
I did a quick look and found the bug...it's a quick and easy fix. The dev is updating client right now. It's looking like block reward will half at 55,000 then again at 95,000.
summary of old and new block rewards:
old:
50K blocks @ 10 = 500,000 (up to block 50,000)
50K blocks @ 5 = 250,000 (up to block 100,000)
750K coins
New fix:
55K blocks @ 10 = 550,000 (up to block 55,000)
40k blocks @ 5 = 200,000 (up to block 95,000)
750K coins
|
|
|
|
@Mullick you're working on both CGB and CAP at the same time?
No, Mullick is being Mullick...that is, helpful If devs (both project and network) helped each other out instead of competed, altcoins would fucking rock the world... |
|
|
|
any update for this yet  ? or if anyone can help me get the network hash rate please /cryptobulliond getmininginfo { "blocks" : 47211, "currentblocksize" : 1000, "currentblocktx" : 0, "difficulty" : 3.77935472, "errors" : "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers.", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "pooledtx" : 0, "testnet" : false Checkpoint warning is back Im sure satishi is on it  No worries wont affect anything just a friendly reminded to miners an update should be out soon Yes, client update soon. Thanks. btw, loving that cheap CAP...nom nom  |
|
|
|
Yep this was a pool problem... blocks are definitely being solved at the rate that they should.
Yep. I'm going to match the bounty for a third pool, bringing it up to 100 CGB for a third pool. I have setup a CryptogenicBullion STRATUM PPLNS Pool and its working fine, so you are welcome to join and spread the network hashrate. I have set pool fees to only 1%, 60 block confirms for fast payouts, and only 0.01 CGB payout fee to pay the actual transaction fee. cgb.minar.ccStart your miner using the following parameters: | URL: | stratum+tcp://cgb.minar.cc | | PORT: | 3337 | | USER: | username.worker | | PASS: | workerPass |
Sample command-line: ./cgminer -o stratum+tcp://cgb.minar.cc:3337 --scrypt -u username.worker -p workerPass Please let me know if you find anything out of normal, comments and suggestions also welcome! New Pool Up and running! Please let me know if you find anything out of normal, comments and suggestions also welcome! Thanks. |
|
|
|
the Caps arrived at their destination .
thank you for your support in this matter.
hopefully with a new client and some work these things could be resolved in the future .
Good. I'm glad. I'm not a dev of CAP but I honestly believe an attack on any coin is an attack on altcoins as a whole. And I don't want to see people lose money because of the actions of these tech bullies. -Merc This is the first I'm hearing of an attack on the CAP network. Could you please post the link? No one knows what happened or how it happened. And there was talk that maybe there was an attempted attack while multipool switched to CAP (because the big jump in network hashrate would camouflage an attacker). But pure speculation and nothing more. So when this guy said his coins went through, I was glad that an 'attack' or whatever it was didn't cause him to lose his coins. I should have quoted the word 'attack'. Good news is that PoS blocks should be kicking in and security of the network will be increasing by each minute. Cheers! |
|
|
|
the Caps arrived at their destination .
thank you for your support in this matter.
hopefully with a new client and some work these things could be resolved in the future .
Good. I'm glad. I'm not a dev of CAP but I honestly believe an attack on any coin is an attack on altcoins as a whole. And I don't want to see people lose money because of the actions of these tech bullies. -Merc I really don't think anyone is a "Tech bully" - its a market mechanism , i generally support multi-pools as they are just another innovation, although i do not use them as i can be more efficient manually . they don't bother me in the slightest. - if the Caps were lost they were lost - i would make it known and so would others , then support and confidence would drop on the currency etc. this is also a mechanism of an informational market , so if there is no solution then confidence will be ultimately eroded. this is not miners fault , that's a little childish to say so , if there are sCrypt ASICs out now, then in a larger scale they will do the same thing to larger environment. and so it goes. You completely misunderstood what I said. The 'tech bully' was in reference to a attacker, for example, on FTC network with several Gh/s. That's a tech bully. I didn't even mention multipool...what are you smoking? lol |
|
|
|
the Caps arrived at their destination .
thank you for your support in this matter.
hopefully with a new client and some work these things could be resolved in the future .
Good. I'm glad. I'm not a dev of CAP but I honestly believe an attack on any coin is an attack on altcoins as a whole. And I don't want to see people lose money because of the actions of these tech bullies. -Merc |
|
|
|
Happy that a 24/24 monitoring and immediate update to 100 confirmations deposit with a special checking on each then TRC deposit, helped crypto-trade.com to be safe of such lost.
here something else I don't understand during the attack 100 confirmations were a matter of a few minutes... since the blocks were generated with very high frequency... what difference did it make? Letting few minutes more to check more about big deposits. When you see 120k trc coming if you monitor as you know it is attacked, you usually suspect something...And lock the user for more investigation Even smaller amount looking enornous compar to usual... Of course as said 24/24 monitoring is needed... Or the TRC trading should be stopped directly before any disaster... I agree on that Happy that a 24/24 monitoring and immediate update to 100 confirmations deposit with a special checking on each then TRC deposit, helped crypto-trade.com to be safe of such lost.
here something else I don't understand during the attack 100 confirmations were a matter of a few minutes... since the blocks were generated with very high frequency... what difference did it make? None. Coinotron had over 100 confirmed blocked they mined erased by the attacker before they suspended the TRC pool. The difficulty exploit made the attack unstoppable for the most part. In the main thread discussing the attack we were surprised trading was open at all. I agree while coinotron is a pool, managed by only one operator. Pool also dont earn same fees than exchange and dont push same risk on users. We can understand that coinotron took time to react. An exchange shouln't run if is not 24/24 monitored, my opinion remains the same about this. I completely agree. Good to know you have the proper safety checks at crypto-trade. I know Cryptsy also had alerts triggered and disabled accounts. Your efforts will help keep damage to altcoins to a minimum as the industry continues to mature, and for that I thank you. -Merc |
|
|
|
It's good to be critical, but leave out the insults and read closely.
Baritus: "I'm just gauging community opinion with the poll, you can be assured no decisions are ever made in this community without input from all members." - Great!
"I definitely see both sides of the argument and I am currently siding with keeping it as is or a slight decrease (10-20%)." - Understood. Even if I still think it's a bad idea.
"Nevertheless, polls are one of the few ways of gathering information so don't be surprised to see them coming up. It doesn't mean anything but an opinion gauge. Good discussion, if anyone has anything else to add, please do." - It's good to have polls!
mercSue: "Are you the dev of DGC or are you its price manipulator?" - Rightful question dev has to live with if he considers changing the rewards.
"And now you want to change DGC into the biggest premined coin in all history of premined coins." - It wouldn't technically be a premine, but it was clear this proposal could cause anger and concern.
"Congrats, you have turned what's supposed to be a decentralized system into a centralized one." - He hasn't done anything, and even if he did, DGC would still be a decentralized coin, unlike ripple for example
"By the way, how's that mining contract of yours coming along?" - Is this related to DGC at all?
"Respectfully, the fact you would even consider this shows how clueless you are..." - This sentence is antagonizing and should have been dropped. And writing "respectfully" doesn't make it any less so.
DannyDisco: "What I'd like to see done, is have some sort of mechanism that blocks large amounts of hashrate to be dumped on a coin. Not sure if it's possible... but say if a pool with more than 40% of the current hashrate tries to mine.. it simply gets blocked and no work gets sent to it." - This is what we should be focusing about.
Thanks for the post. I despise anything resembling the actions of a central authority akin to the Federal Reserve. And this was how I interpreted Baritus's (possible) actions. The mining contract thing goes back to when DGC was released. I'll find the posts (it's like on page six or something), but I found it so insulting that I question Baritus's motives sometimes. He's a nice guy and an active dev but then he'll do these really questionable things like the mining contract during DGC release when it would behoove the blockchain to have more trusted miners mining. Or, for instance, ignoring the reputation of a certain notorious troll on this forum and welcoming him onto DGC's dev team (that was when I sold my holdings of DGC btw). And now considering to change the coin subsidy when changing the diff retarget algo should be considered first. -Merc |
|
|
|
Federal Reserve of Baritus and his cronies....
What is your deal? Quit making yourself look stupid mate. I know many of you own DGC and my sentiment won't be all that popular. So just answer this question, smarty. And if I'm wrong, then I'm wrong. But is changing the subsidy and coin supply motivated primarily because people are unsatisfied with DGC's price action? No. It is merely a suggestion to dissuade large pool hoping pools from connecting and taking advantage of the coin. It's a solution to protect the investors. It's a controversial one, but at least it's a suggestion. Rather than blast the devs and call them thieves or price manipulators, why don't you offer up a different suggestion and try to help? Fair enough. It is controversial, for sure. My suggestion. Don't touch the coin supply. Change difficulty retarget algo to be on a per block basis of an average of last X block times. So if the DGC blockchain is hit with large hashrate then diff should retarget quickly and consequently so will profitability. If this algo is implemented I'll buy back my 200k DGC. Cheers! -Merc |
|
|
|
|
Show Posts
