GoldCoin Talk
Main Category => GoldCoin Discussion => Important Bulletins => Topic started by: akumaburn on May 11, 2015, 10:52:04 PM
-
The 7.1.8 update has been released, and you are all advised to update immediately.
This update is hard-forking at block 248,000. At which point the difficulty algorithm will be revised to allow for more even block find times(to address the current situation of absurd transaction confirmation times).
You can download the release here: http://www.gldcoin.com/get-started/ (http://www.gldcoin.com/get-started/)
You can confirm whether or not you have a valid release, if interested, by running an SHA1 checksum against the values below.
goldcoin-0.7.1.8-1-win32-setup.exe – SHA1 – bd06000f7dab0bb7c94688430350767be2516686
goldcoin-0.7.1.8-linux.tar.xz - SHA1 - 77460c8af0f4ee6ffbee5b6aeadfd0d69c6f21b6
goldcoin-0.7.1.8-mac-osx.dmg - SHA1 - 8019a202bc84afc404115654df20b278e424acbb
-
Great news on the update. Only 501 blocks to go.
-
Only 501 blocks to go.
(http://i.giphy.com/Ou2TE0mP4QbcI.gif)
-
The windows binary has been updated to fix a daemon issue. (This only affects windows daemons not GUIs or daemons from other releases).
-
We are on the new fork gentlemen! ;D
(https://www.goldcointalk.org/devteam/newfork.jpg)
Block explorer >> http://gld.cryptocoinexplorer.com/
-
I believe the fork actually starts at block 248040, because that is the next 60 block interval on or after block 248000.
Strangely, the block explorer at gld.cryptocoinexplorer.com reports block 248058, but all of my clients (two computers running 0.7.1.8 and the android app) are stopping syncing at 248039.
My debug log shows:
received block df28a9658eb598212f2c
Entered CheckSetBestChain: new best=df28a9658eb598212f2c height=248037 work=20428955499694724 date=05/17/15 02:36:18
ProcessBlock: ACCEPTED
received block 8b93f05601f299691533
Entered CheckSetBestChain: new best=8b93f05601f299691533 height=248038 work=20429214834938062 date=05/17/15 02:37:09
ProcessBlock: ACCEPTED
received block 290cc1c70f12caec95bc (Stouse49's note: this is block 240039)
Entered CheckSetBestChain: new best=290cc1c70f12caec95bc height=248039 work=20429474170181400 date=05/17/15 02:39:23
ProcessBlock: ACCEPTED
received block dfb2278419b5b729648d
trying connection 78.144.238.92:8121 lastseen=13033.7hrs
Median Time between blocks is: 113
GetNextWorkRequired(): May Fork mode
GetNextWorkRequired(): Average time between blocks over the last 120 blocks is: 142
Medium Time between blocks is too low compared to average time.. Attempting to Adjust..
nActualTimespan = 6600 before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 7200 nActualTimespan = 6600
Before: 1c043d5f 00000000043d5f00000000000000000000000000000000000000000000000000
After: 1c03e2ec 0000000003e2ec6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
disconnecting node 71.175.81.45:8121
Disconnected 71.175.81.45:8121 for misbehavior (score=100)
The android app has not been updated, so its stopping at block 240039 makes sense.
Here is my peer information.
00:55:21

getpeerinfo
00:55:21

[
{
"addr" : "99.253.2.126:8121",
"services" : "00000001",
"lastsend" : 1431848854,
"lastrecv" : 1431848062,
"conntime" : 1431846211,
"version" : 60015,
"subver" : "/Satoshi:0.7.1.8/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 247277,
"banscore" : 0
},
{
"addr" : "167.160.36.162:8121",
"services" : "00000001",
"lastsend" : 1431848855,
"lastrecv" : 1431848702,
"conntime" : 1431846212,
"version" : 60015,
"subver" : "/Satoshi:0.7.1.8/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 248058,
"banscore" : 0
},
{
"addr" : "72.78.100.9:8121",
"services" : "00000001",
"lastsend" : 1431848144,
"lastrecv" : 1431848144,
"conntime" : 1431846213,
"version" : 60015,
"subver" : "/Satoshi:0.7.1.8/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 248058,
"banscore" : 0
},
{
"addr" : "108.61.10.90:8121",
"services" : "00000001",
"lastsend" : 1431848456,
"lastrecv" : 1431848854,
"conntime" : 1431846225,
"version" : 60015,
"subver" : "/Satoshi:0.7.1.8/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 248058,
"banscore" : 0
},
{
"addr" : "107.161.23.159:8121",
"services" : "00000001",
"lastsend" : 1431848144,
"lastrecv" : 1431848144,
"conntime" : 1431846226,
"version" : 60015,
"subver" : "/Satoshi:0.7.1.8/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 248058,
"banscore" : 0
}
]
-
Yep, the fork affects the NEXT difficulty change. Which you are correct in assuming is 248040.
-
Strangely, the block explorer at gld.cryptocoinexplorer.com reports block 248058, but all of my clients (two computers running 0.7.1.8 and the android app) are stopping syncing at 248039.
All of my clients have also stopped syncing. I'm just getting up but will try some test transactions shortly.
-
I am not sure why my client stopped at 248039 last night. Now it is at 248063, this morning. It was connected to some version 0.7.1.7 clients, which may have been the ones sending the bad blocks (which are on the wrong fork).
Based on the log, the new code was triggered, but the difficulty was raised.
ProcessBlock: ORPHAN BLOCK, prev=36dc2e7b01ef3c61e4c6
received block 5a8fef433c8e9bbff479
Median Time between blocks is: 113
GetNextWorkRequired(): May Fork mode
GetNextWorkRequired(): Average time between blocks over the last 120 blocks is: 142
Medium Time between blocks is too low compared to average time.. Attempting to Adjust..
nActualTimespan = 6600 before bounds
GetNextWorkRequired RETARGET
nTargetTimespan = 7200 nActualTimespan = 6600
Before: 1c043d5f 00000000043d5f00000000000000000000000000000000000000000000000000
After: 1c03e2ec 0000000003e2ec6aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
-
Thank you for this reply Eric. Did the difficulty not increase from 60.38 to 65.86 at the fork?
http://gld.cryptocoinexplorer.com/blockrange?range=100
I also wanted to report that my desktop client is now in sync. :)
-
Thank you for this reply Eric. Did the difficulty not increase from 60.38 to 65.86 at the fork?
http://gld.cryptocoinexplorer.com/blockrange?range=100
I also wanted to report that my desktop client is now in sync. :)
Yes it did.
I noticed a large increase in hash rate before the fork and difficulty adjustment. The added hash rate, though most likely well intentioned to get to the new fork-difficulty adjustment, may have accidentally caused the difficulty adjustment to go up instead of down.
On a side note, I had some issues with the explorer and an orphan block older then 250 blocks. The explorer is set to check for orphans 250 blocks back from the current every time block notify calls the loader, I tracked down the bad block and manually ran it through the orphan correction routine.So far that is the only strangeness I have noticed with the fork. I do not know if there are more, but if anyone runs into a transaction in a block on the explorer that comes up as not found, let me know.
-
Whenever the hashrate spikes like that(We were at 1.6GH/s earlier), there might be 6 blocks mined in 10 minutes and the 51% defense gets triggered and there is a slight diff increase regardless of what the average block time is.
Overall though, we should see more consistent block times from now on as that is a fringe scenario that shouldn't be in any way be considered normal.
If you think about it.. the hash rate tippling making the difficulty increase is desired behavior.
It's just unfortunate in this particular case.
Edit:
Upon further examination..
It seems the 51% wasn't actually triggered here..
See what happened was this particular code block was triggered.
else if(averageTime >= 108 && medTime < 120) {
//If the average time between blocks is more than 1.8 minutes and medTime is less than 120 seconds (which would ordinarily prompt an increase in difficulty)
//limit the stepping to something reasonable(so we don't see massive difficulty spike followed by miners leaving in these situations).
medTime = 110;
printf(" \n Medium Time between blocks is too low compared to average time.. Attempting to Adjust.. \n ");
}
Normally when medTime is less than 120 seconds the difficulty increases no matter what, but this essentially fixes that increase to 1/12th or 8.3% per diff change so long as the average time between blocks seems reasonable(average time between blocks is not equal to or greater than 3 minutes).
-
I think this explains it:
http://www.coinwarz.com/network-hashrate-charts/goldcoin-network-hashrate-chart
https://www.litecoinpool.org/calc?hashrate=1700&speedunit=MH%2Fs&difficulty=60&power=&energycost=0.10¤cy=USD
-
I have updated the android app. It is syncing past the hard fork.
Google took the app off the market, but I changed what needed to be updated so hopefully it goes back online soon.
-
I have updated the android app. It is syncing past the hard fork.
Google took the app off the market, but I changed what needed to be updated so hopefully it goes back online soon.
Thanks for updating the Android app. I found it in the playstore and used the update option. Seems to be working brilliantly! ;D
-
I have updated the android app. It is syncing past the hard fork.
Google took the app off the market, but I changed what needed to be updated so hopefully it goes back online soon.
(https://www.goldcointalk.org/devteam/stalled_android.jpg)
The Android app was working great up until about 4 days ago. Now I'm getting a "synchronization stalled, 4 days behind" message.
Do you think resetting the blockchain could help?
-
What block is your block explorer stuck at?
Mine is at 249539 from June 28. I get three peers.
Something must have gone wrong with the difficulty calculation at block 249540.
-
What block is your block explorer stuck at?
Mine is at 249539 from June 28. I get three peers.
Something must have gone wrong with the difficulty calculation at block 249540.
Thanks for investigating this issue. :)
My block explorer is also stuck on block 249539. I'm currently connected to 5 peers.
-
I have verified using android app logs that the block 249540 the difficulty adjustment code has a bug. The fork was at block 248000, but I have seen it before that a bug happens much later than when the code change is activated.
This is a problem in the app. It does not match what the desktop client is doing.
-
Is the buggy code on the Github?
I wonder if we could post a link to the code lines in question and get suggestions like you see here: https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b
-
The code is not on Github. I forgot to push the latest updates. I will make sure it gets updated.
-
The github repo has been updated.
-
The github repo has been updated.
Thanks Eric. It looks like Amir will be releasing the 'Golden River' patch on or around Sunday.
Once the new patch is released, I think the top 2 things on our agenda should be getting listed again on Bittrex (or another exchange) and getting the Android app working again.