Quote from: DigiByte on April 05, 2017, 01:10:53 PM

Quick update, we have one final hurdle to get through before we release v6.14.1. The upcoming soft fork will consist of 4 phases as defined here: https://github.com/digibyte/digibyte/blob/6.14.1devnet/src/versionbits.h#L20

Code:

enum ThresholdState {
   THRESHOLD_DEFINED,
   THRESHOLD_STARTED,
   THRESHOLD_LOCKED_IN,
   THRESHOLD_ACTIVE,
   THRESHOLD_FAILED,
};

These soft forks will be carried out according to bip 9 as described here: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

The parameters for our soft fork are defined here: https://github.com/digibyte/digibyte/blob/6.14.0/src/chainparams.cpp#L145

THRESHOLD_DEFINED - Currently our mining tests work through here without issues.

THRESHOLD_STARTED - This is where we are having mining problems with testing. (Period already started, period is 1 week requiring 70% of previous 40,320 blocks to advance to next phase). We get "Unrecognized block version" on most miners when mining through this phase, although some mining software still mines blocks.

THRESHOLD_LOCKED_IN - Same as Started

THRESHOLD_ACTIVE - Once we hit activation everything works as it should on all mining software.

The new block version bits as defined in bip 9 are defined here: https://github.com/digibyte/digibyte/blob/6.14.0/src/versionbits.h#L14

Code:

static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
/** What bitmask determines whether versionbits is in use */
static const int32_t VERSIONBITS_TOP_MASK = 0xE0000000UL;
/** Total bits available for versionbits */
static const int32_t VERSIONBITS_NUM_BITS = 28;

The issue is a combination of Multi-Algo versioning, plus bip 9 soft fork roll out versioning.

Our Multi-Algo block bit versioning is defined with this bitwise operator here: https://github.com/digibyte/digibyte/blob/6.14.0/src/primitives/block.h#L30

Code:

enum
{
   // primary version
   BLOCK_VERSION_DEFAULT = 4,

   // algo
   BLOCK_VERSION_ALGO = (7 << 9),
   BLOCK_VERSION_SCRYPT = (1 << 9),
   BLOCK_VERSION_SHA256D = (1 << 9),
   BLOCK_VERSION_GROESTL = (2 << 9),
   BLOCK_VERSION_SKEIN = (3 << 9),
   BLOCK_VERSION_QUBIT = (4 << 9),
};

When mining through a test network and all the phases here are the block versions we are getting converted to binary and hex:

Code:

Version= 0010 0000 0000 0000 0000 1110 0000 0111 - 20000007 - Scrypt -- STARTED - LOCKEN_IN
Version= 0010 0000 0000 0000 0000 1110 0000 0000 - 20000000 - Scrypt -- DEFINED - ACTIVE
Version= 0010 0000 0000 0000 0000 0010 0000 0111 - 20000207 - Sha256 -- STARTED - LOCKEN_IN
Version= 0010 0000 0000 0000 0000 0010 0000 0000 - 20000200 - Sha256 -- DEFINED - ACTIVE
Version= 0010 0000 0000 0000 0000 0100 0000 0111 - 20000407 - Groestl -- STARTED - LOCKEN_IN
Version= 0010 0000 0000 0000 0000 0100 0000 0000 - 20000400 - Groestl -- DEFINED - ACTIVE
Version= 0010 0000 0000 0000 0000 0110 0000 0111 - 20000607 - Skein -- STARTED - LOCKEN_IN
Version= 0010 0000 0000 0000 0000 0110 0000 0000 - 20000600 - Skein -- DEFINED - ACTIVE
Version= 0010 0000 0000 0000 0000 1000 0000 0111 - 20000807 - Qubit -- STARTED - LOCKEN_IN
Version= 0010 0000 0000 0000 0000 1000 0000 0000 - 20000800 - Qubit -- DEFINED - ACTIVE

So the identifier to far right that flags segwit support etc is causing issues (the 7 at end). Anyone have any suggestions?

Current dev branch we are working and testing out of: https://github.com/digibyte/digibyte/commits/6.14.1devnet

GRS devs can sort this out for you for a price , you won't have much luck with arrogant Gulden devs or untouchable litecoin devs who have already done the update.