well.. I restarted the gld.minepool.net pool up again and its hitting blocks. We're still on the same chain as cryptsy.com too. I set up a new goldcoin pool on another server and network here in hopes of getting some of the miners to disperse!
gld.cryptcoins.net
I'm assuming that if we don't spread out .. its all going to happen all over again...and it then seems to affect the whole hasing network overall, not just the one mining pool.
Topic: GoldCoin™ (GLC) Thread - The Gold Standard of Digital Currency [OFFICIAL THREAD] - page 72. (Read 310011 times)
November 26, 2013, 07:37:40 AM
November 26, 2013, 05:52:40 AM
Our pool got to over 200Mhs and had many problems. Many successful blocks but now all orphans.
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Your pool never mined on the official chain.
You created a fork instantly and ran with it, hence all the orphans.
~BCX~
Not true.. it was on the same chain as cryptsy's client the whole time. I did test transactions to cryptsy to check.
It was doing the same thing several other people's clients are doing. Hoping chains.
I'm not knocking GLD, quite the opposite.
Hope they get this solved.
~BCX~
That sounds about right. I believe somehow the 51% attack defense eventually led to the pool forking.. maybe all of them. Solo mining with only 1Mhs on a separate coin client.. i got the same thing.
November 26, 2013, 05:47:06 AM
Our pool got to over 200Mhs and had many problems. Many successful blocks but now all orphans.
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Your pool never mined on the official chain.
You created a fork instantly and ran with it, hence all the orphans.
~BCX~
Not true.. it was on the same chain as cryptsy's client the whole time. I did test transactions to cryptsy to check.
It was doing the same thing several other people's clients are doing. Hoping chains.
I'm not knocking GLD, quite the opposite.
Hope they get this solved.
~BCX~
November 26, 2013, 05:44:06 AM
Our pool got to over 200Mhs and had many problems. Many successful blocks but now all orphans.
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Your pool never mined on the official chain.
You created a fork instantly and ran with it, hence all the orphans.
~BCX~
Not true.. it was on the same chain as cryptsy's client the whole time. I did test transactions to cryptsy to check.
November 26, 2013, 05:20:26 AM
The situation with the 51% defense is ridiculous. Not only this smartass algorithm prevents 51% attacks, it also prevents anyone from mining this coin! I'm "the little guy" here, too, with only 2 Mh/s. Now I can't mine solo (getting 100% rejects), and I can't mine on pools (getting almost 100% orphans). Maybe this new defense is really good in theory, but in practice it's just killing this coin. Devs, fix this ASAP because nobody's gonna mine GLD if they can't get any profit and just waste their electricity.
November 26, 2013, 05:09:30 AM
I hate to say it but goldcoin was better without the new 51% defense. I don't want to waste power mining when I don't get anything for it. Nothing against the dev's or anything just my own opinion. just makes it really hard to mine legit wise.
Same thing over at Coinex
https://coinex.pw/mining/pools/GLD
Gold has left the building!
Please make your way slowly and orderly to another coin!
November 26, 2013, 05:07:05 AM
I hate to say it but goldcoin was better without the new 51% defense. I don't want to waste power mining when I don't get anything for it. Nothing against the dev's or anything just my own opinion. just makes it really hard to mine legit wise.
November 26, 2013, 04:57:57 AM
Our pool got to over 200Mhs and had many problems. Many successful blocks but now all orphans.
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Your pool never mined on the official chain.
You created a fork instantly and ran with it, hence all the orphans.
~BCX~
November 26, 2013, 04:40:16 AM
Our pool got to over 200Mhs and had many problems. Many successful blocks but now all orphans.
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
Perhaps this was a contribution to the coin's problem right now? It really needs ...something. The 51% protection works i suppose since the pool became more than 51% of the mining (i'm guessing) I don't know what to tell the miners now who are still miming. Im going to shut it down soon to see what happens. gld.minepool.net
November 26, 2013, 03:30:13 AM
+++1 I love goldcoin but can't get it to mine and I am the little guy you speak of.
November 26, 2013, 03:29:28 AM
@MicroGuy or Akumaburn
You've definitely have some multiple forking issues going on.
I tried GLD (solo mining) for the first time, found 26 blocks and had 1170 GLD, some confirmed and some still immature when apparently the client re-synced with a rouge chain and wiped out the previous mined GLD. I think it is related to your 51% attack solution but can't say for sure as I haven't looked at the source or tested beyond my initial mining effort.
Also I tried initially mining at 10 mhs which isn't a significant amount for me. Until I dialed it back to 5 mhs, every block I found was rejected. I assume this is also an issue with your 51% solution. So in effect, the maximum any miner can mine with is less than 49% of nethash to keep from triggering the 5 blocks in 10 minutes trigger. With these kinds of restrictions/issues and the nethash only at 16mhs, it's going to be very hard to increase the nethash to any appreciable rate.
Hope to see you fix this chain.
~BCX~
+1You've definitely have some multiple forking issues going on.
I tried GLD (solo mining) for the first time, found 26 blocks and had 1170 GLD, some confirmed and some still immature when apparently the client re-synced with a rouge chain and wiped out the previous mined GLD. I think it is related to your 51% attack solution but can't say for sure as I haven't looked at the source or tested beyond my initial mining effort.
Also I tried initially mining at 10 mhs which isn't a significant amount for me. Until I dialed it back to 5 mhs, every block I found was rejected. I assume this is also an issue with your 51% solution. So in effect, the maximum any miner can mine with is less than 49% of nethash to keep from triggering the 5 blocks in 10 minutes trigger. With these kinds of restrictions/issues and the nethash only at 16mhs, it's going to be very hard to increase the nethash to any appreciable rate.
Hope to see you fix this chain.
~BCX~
Just mined for a few hours. Kept watching my freshly minted GLD #'s roll backwards. Not Cool.
November 26, 2013, 01:47:49 AM
@MicroGuy or Akumaburn
You've definitely have some multiple forking issues going on.
I tried GLD (solo mining) for the first time, found 26 blocks and had 1170 GLD, some confirmed and some still immature when apparently the client re-synced with a rouge chain and wiped out the previous mined GLD. I think it is related to your 51% attack solution but can't say for sure as I haven't looked at the source or tested beyond my initial mining effort.
Also I tried initially mining at 10 mhs which isn't a significant amount for me. Until I dialed it back to 5 mhs, every block I found was rejected. I assume this is also an issue with your 51% solution. So in effect, the maximum any miner can mine with is less than 49% of nethash to keep from triggering the 5 blocks in 10 minutes trigger. With these kinds of restrictions/issues and the nethash only at 16mhs, it's going to be very hard to increase the nethash to any appreciable rate.
Hope to see you fix this chain.
~BCX~
You've definitely have some multiple forking issues going on.
I tried GLD (solo mining) for the first time, found 26 blocks and had 1170 GLD, some confirmed and some still immature when apparently the client re-synced with a rouge chain and wiped out the previous mined GLD. I think it is related to your 51% attack solution but can't say for sure as I haven't looked at the source or tested beyond my initial mining effort.
Also I tried initially mining at 10 mhs which isn't a significant amount for me. Until I dialed it back to 5 mhs, every block I found was rejected. I assume this is also an issue with your 51% solution. So in effect, the maximum any miner can mine with is less than 49% of nethash to keep from triggering the 5 blocks in 10 minutes trigger. With these kinds of restrictions/issues and the nethash only at 16mhs, it's going to be very hard to increase the nethash to any appreciable rate.
Hope to see you fix this chain.
~BCX~
November 26, 2013, 01:26:35 AM
any way to mine? quit for another coins now (
November 25, 2013, 09:25:55 PM
That will be because your peers are still set to 45sec. nothing you can do about that except be selective about peers.
any way to detect what peers are good?
November 25, 2013, 09:24:33 PM
can you upload wallet with 300 sec plz )
Thank you
Thank you
No point, here are the results:
Standard 45 second wallet - orphan, orphan, orphan, orphan, orphan, orphan, orphan
Modified 300 second wallet - orphan, orphan, orphan, orphan, orphan, orphan, orphan
November 25, 2013, 09:22:58 PM
can you upload wallet with 300 sec plz )
Thank you
Thank you
No point, here are the results:
Standard 45 second wallet - orphan, orphan, orphan, orphan, orphan, orphan, orphan
Modified 300 second wallet - orphan, orphan, orphan, orphan, orphan, orphan, orphan
November 25, 2013, 08:59:49 PM
I've made your suggested main.cpp change from 45 to 300 seconds, recompiled and restarted the wallet. I'll let you know if I see any better results 
can you upload wallet with 300 sec plz )
Thank you
November 25, 2013, 08:54:33 PM
I've made your suggested main.cpp change from 45 to 300 seconds, recompiled and restarted the wallet. I'll let you know if I see any better results
November 25, 2013, 08:45:48 PM
Can we get a list of peer IP's that are known to be on the right time?
You can set your computer to the right time, but it doesn't mean your peers are when you try and send them a newly mined
block, so you may still get an orphan even though you are on the correct time, just because your peers are not.
You can set your computer to the right time, but it doesn't mean your peers are when you try and send them a newly mined
block, so you may still get an orphan even though you are on the correct time, just because your peers are not.
In util.cpp on line 1161 change
Code:
void SetMockTime(int64 nMockTimeIn)
{
nMockTime = nMockTimeIn;
}
static int64 nTimeOffset = 0;
int64 GetAdjustedTime()
{
return GetTime() + nTimeOffset;
}
void AddTimeData(const CNetAddr& ip, int64 nTime)
{
int64 nOffsetSample = nTime - GetTime();
// Ignore duplicates
static set setKnown;
if (!setKnown.insert(ip).second)
return;
// Add data
vTimeOffsets.input(nOffsetSample);
printf("Added time data, samples %d, offset %+"PRI64d" (%+"PRI64d" minutes)\n", vTimeOffsets.size(), nOffsetSample, nOffsetSample/60);
if (vTimeOffsets.size() >= 5 && vTimeOffsets.size() % 2 == 1)
{
int64 nMedian = vTimeOffsets.median();
std::vector vSorted = vTimeOffsets.sorted();
// Only let other nodes change our time by so much
if (abs64(nMedian) < 35 * 60) // GoldCoin (GLD): changed maximum adjust to 35 mins to avoid letting peers change our time too much in case of an attack.
{
nTimeOffset = nMedian;
}
else
{
nTimeOffset = 0;
static bool fDone;
if (!fDone)
{
// If nobody has a time different than ours but within 5 minutes of ours, give a warning
bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 5 * 60)
fMatch = true;
if (!fMatch)
{
fDone = true;
string strMessage = _("Warning: Please check that your computer's date and time are correct. If your clock is wrong GoldCoin (GLD) will not work properly.");
strMiscWarning = strMessage;
printf("*** %s\n", strMessage.c_str());
uiInterface.ThreadSafeMessageBox(strMessage+" ", string("GoldCoin (GLD)"), CClientUIInterface::OK | CClientUIInterface::ICON_EXCLAMATION);
}
}
}
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
}
}
{
nMockTime = nMockTimeIn;
}
static int64 nTimeOffset = 0;
int64 GetAdjustedTime()
{
return GetTime() + nTimeOffset;
}
void AddTimeData(const CNetAddr& ip, int64 nTime)
{
int64 nOffsetSample = nTime - GetTime();
// Ignore duplicates
static set
if (!setKnown.insert(ip).second)
return;
// Add data
vTimeOffsets.input(nOffsetSample);
printf("Added time data, samples %d, offset %+"PRI64d" (%+"PRI64d" minutes)\n", vTimeOffsets.size(), nOffsetSample, nOffsetSample/60);
if (vTimeOffsets.size() >= 5 && vTimeOffsets.size() % 2 == 1)
{
int64 nMedian = vTimeOffsets.median();
std::vector
// Only let other nodes change our time by so much
if (abs64(nMedian) < 35 * 60) // GoldCoin (GLD): changed maximum adjust to 35 mins to avoid letting peers change our time too much in case of an attack.
{
nTimeOffset = nMedian;
}
else
{
nTimeOffset = 0;
static bool fDone;
if (!fDone)
{
// If nobody has a time different than ours but within 5 minutes of ours, give a warning
bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 5 * 60)
fMatch = true;
if (!fMatch)
{
fDone = true;
string strMessage = _("Warning: Please check that your computer's date and time are correct. If your clock is wrong GoldCoin (GLD) will not work properly.");
strMiscWarning = strMessage;
printf("*** %s\n", strMessage.c_str());
uiInterface.ThreadSafeMessageBox(strMessage+" ", string("GoldCoin (GLD)"), CClientUIInterface::OK | CClientUIInterface::ICON_EXCLAMATION);
}
}
}
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
}
}
To
Code:
void SetMockTime(int64 nMockTimeIn)
{
nMockTime = nMockTimeIn;
}
static int64 nTimeOffset = 0;
int64 GetAdjustedTime()
{
return GetTime() + nTimeOffset;
}
void AddTimeData(const CNetAddr& ip, int64 nTime)
{
int64 nOffsetSample = nTime - GetTime();
// Ignore duplicates
static set setKnown;
if (!setKnown.insert(ip).second)
return;
// Add data
vTimeOffsets.input(nOffsetSample);
printf("Added time data, samples %d, offset %+"PRI64d" (%+"PRI64d" minutes)\n", vTimeOffsets.size(), nOffsetSample, nOffsetSample/60);
if (vTimeOffsets.size() >= 5 && vTimeOffsets.size() % 2 == 1)
{
int64 nMedian = vTimeOffsets.median();
std::vector vSorted = vTimeOffsets.sorted();
// Only let other nodes change our time by so much
if (abs64(nMedian) < 35 * 60) // GoldCoin (GLD): changed maximum adjust to 35 mins to avoid letting peers change our time too much in case of an attack.
{
nTimeOffset = nMedian;
}
else
{
nTimeOffset = 0;
static bool fDone;
if (!fDone)
{
// If nobody has a time different than ours but within 10 seconds of ours, give a warning
bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 10)
fMatch = true;
if (!fMatch)
{
fDone = true;
string strMessage = _("Warning: Please check that your computer's date and time are correct. If your clock is wrong GoldCoin (GLD) will not work properly.");
strMiscWarning = strMessage;
printf("*** %s\n", strMessage.c_str());
uiInterface.ThreadSafeMessageBox(strMessage+" ", string("GoldCoin (GLD)"), CClientUIInterface::OK | CClientUIInterface::ICON_EXCLAMATION);
}
}
}
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
}
}
And recompile{
nMockTime = nMockTimeIn;
}
static int64 nTimeOffset = 0;
int64 GetAdjustedTime()
{
return GetTime() + nTimeOffset;
}
void AddTimeData(const CNetAddr& ip, int64 nTime)
{
int64 nOffsetSample = nTime - GetTime();
// Ignore duplicates
static set
if (!setKnown.insert(ip).second)
return;
// Add data
vTimeOffsets.input(nOffsetSample);
printf("Added time data, samples %d, offset %+"PRI64d" (%+"PRI64d" minutes)\n", vTimeOffsets.size(), nOffsetSample, nOffsetSample/60);
if (vTimeOffsets.size() >= 5 && vTimeOffsets.size() % 2 == 1)
{
int64 nMedian = vTimeOffsets.median();
std::vector
// Only let other nodes change our time by so much
if (abs64(nMedian) < 35 * 60) // GoldCoin (GLD): changed maximum adjust to 35 mins to avoid letting peers change our time too much in case of an attack.
{
nTimeOffset = nMedian;
}
else
{
nTimeOffset = 0;
static bool fDone;
if (!fDone)
{
// If nobody has a time different than ours but within 10 seconds of ours, give a warning
bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 10)
fMatch = true;
if (!fMatch)
{
fDone = true;
string strMessage = _("Warning: Please check that your computer's date and time are correct. If your clock is wrong GoldCoin (GLD) will not work properly.");
strMiscWarning = strMessage;
printf("*** %s\n", strMessage.c_str());
uiInterface.ThreadSafeMessageBox(strMessage+" ", string("GoldCoin (GLD)"), CClientUIInterface::OK | CClientUIInterface::ICON_EXCLAMATION);
}
}
}
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
}
}
This will warn you that your clock is off by too much in the debug file.
Alternatively you could try syncing with nist automatic time servers.
There is a small tutorial on how to do that here: https://www.gldtalk.org/index.php?topic=730.msg3863#msg3863
November 25, 2013, 08:26:30 PM
I've been looking at my debug.log and see lots of this:
ERROR: CheckBlock() : block timestamp too far in the future
ERROR: ProcessBlock() : CheckBlock FAILED
GetNetworkHashPS(120)
GetTrueNetworkHashPS(120) - modified lookup
best index = 114672
difficulty = 0.435018
hashrate for section: 14.901249 MH/s, time diff = 1385421655 min
====difficulty change at block 114660
height = 114659, difficulty = 0.445892
hashrate for section: 15.959102 MH/s, time diff = 1385414455 min
====difficulty change at block 114600
height = 114599, difficulty = 0.457037
returning hashrate 241.250000 MH/s, lookup 15 (time difference = -0.0)
Ok so server time must be out of sync right? Well:
ntpdate pool.ntp.org
26 Nov 10:30:55 ntpdate[8366]: adjust time server 192.189.54.33 offset -0.102237 sec
0.1 seconds out of sync... umm does this time stuff cater for timezone?
ERROR: CheckBlock() : block timestamp too far in the future
ERROR: ProcessBlock() : CheckBlock FAILED
GetNetworkHashPS(120)
GetTrueNetworkHashPS(120) - modified lookup
best index = 114672
difficulty = 0.435018
hashrate for section: 14.901249 MH/s, time diff = 1385421655 min
====difficulty change at block 114660
height = 114659, difficulty = 0.445892
hashrate for section: 15.959102 MH/s, time diff = 1385414455 min
====difficulty change at block 114600
height = 114599, difficulty = 0.457037
returning hashrate 241.250000 MH/s, lookup 15 (time difference = -0.0)
Ok so server time must be out of sync right? Well:
ntpdate pool.ntp.org
26 Nov 10:30:55 ntpdate[8366]: adjust time server 192.189.54.33 offset -0.102237 sec
0.1 seconds out of sync... umm does this time stuff cater for timezone?
The default maximum wait is 45 seconds, but you can extend this if you want to for optimal acceptance rate.
In main.cpp on lines 2094 to 2107
Code:
else if(QDateTime::fromTime_t(pindexBest->pprev->pprev->pprev->pprev->GetBlockTime()).secsTo(QDateTime::fromTime_t(GetBlockTime())) < (60*10 + 45) && hashPrevBlock == pindexBest->GetBlockHash()) {
//A valid block has been found but the current network adjusted time will not permit it to be accepted by other peers
//Thus we hold the block until GetAdjustedTime() is such that if(GetBlockTime() > GetAdjustedTime() + 45) is false
printf("Local has found possible valid block... queueing until timestamp is valid \n");
//Since we know that GetBlockTime() is greater than GetAdjustedTime()
//We sleep the difference
//Doesn't hurt to check twice
if(GetBlockTime() > GetAdjustedTime() + 45)
Sleep(1000*(GetBlockTime()-(GetAdjustedTime() + 45)));
/*while(GetBlockTime() > GetAdjustedTime() + 45) {
//We wait here..
}*/
}
//A valid block has been found but the current network adjusted time will not permit it to be accepted by other peers
//Thus we hold the block until GetAdjustedTime() is such that if(GetBlockTime() > GetAdjustedTime() + 45) is false
printf("Local has found possible valid block... queueing until timestamp is valid \n");
//Since we know that GetBlockTime() is greater than GetAdjustedTime()
//We sleep the difference
//Doesn't hurt to check twice
if(GetBlockTime() > GetAdjustedTime() + 45)
Sleep(1000*(GetBlockTime()-(GetAdjustedTime() + 45)));
/*while(GetBlockTime() > GetAdjustedTime() + 45) {
//We wait here..
}*/
}
Change (60*10 + 45) to (60*10 + X)
Where X is the maximum amount of time you'd like to hold a block.
And recompile.
Jump to: