[Official] Release of 7.1.8 Mandatory Hard Forking Update

[akumaburn]

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/

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

[Stouse49]

Great news on the update.  Only 501 blocks to go.

[MicroGuy]

Only 501 blocks to go.

[akumaburn]

The windows binary has been updated to fix a daemon issue. (This only affects windows daemons not GUIs or daemons from other releases).

[MicroGuy]

We are on the new fork gentlemen! 



Block explorer >> http://gld.cryptocoinexplorer.com/

[Stouse49]

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.

Code: [Select]

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
}
]


[akumaburn]

Yep, the fork affects the NEXT difficulty change. Which you are correct in assuming is 248040.

[MicroGuy]

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.

[Stouse49]

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.

Code: [Select]

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

[MicroGuy]

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. 

[dreamwatcher]

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.

[akumaburn]

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.

Code: [Select]

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).

[akumaburn]

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&currency=USD

[Stouse49]

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.

[MicroGuy]

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!