★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit

[FryguyUK]

I fricking love loading up on DGB

[1715027010]

1715027010

[1715027010]

1715027010

[1715027010]

1715027010

[1715027010]

1715027010

[pinkman12345]

I fricking love loading up on DGB

Haha same here man! Don't miss the GAME train though!!

[ReSl]

When is DGB Gaming Back?

and please watch your gramma!

We are pausing all payouts until we fix some issues with exploits in payout API interface. Than you for your understanding.

ThanK you!   

[Jumbley]

Quote from Jared today on Telegram.

“To give everyone an update on development we are held up by one remaining issue. We post details in the development channel if anyone wants to look at it on a technical level. Basically during the soft fork the network progresses from "defined" to "started" to "locked in" and finally active. During the "defined" and active phases all 5 mining algos work great. However during the "started" and “locked in phases” most mining software is not recognising the block version due to the signalling of the soft fork combined with multi-algo identifier.
Trying to come up with a solution that does not involve updating all the mining software out there.”

[DigiByte]

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

[GRSisWIN]

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.

[IloveDigibyte]

Make a list of all the coins that have already done this bitcoin code base update and ask them for help. I can donate 5 btc.

1. Gulden
2. Litecoin
3. Groestl

Which other coins have done this and I will add to the list?

[TamiLee]

Make a list of all the coins that have already done this bitcoin code base update and ask them for help. I can donate 5 btc.

1. Gulden
2. Litecoin
3. Groestl

Which other coins have done this and I will add to the list?

Save your money, Jared has enough funds http://www.newsbtc.com/2014/12/02/digibyte-raises-250k-plans-go-global/ , dgb need to find someone who can do the job. I also support Gulden and the community there is desperately waiting on this new Prime project. They won't have time to help out. Groestl devs are your best option.

[DigiByte]

Make a list of all the coins that have already done this bitcoin code base update and ask them for help. I can donate 5 btc.

1. Gulden
2. Litecoin
3. Groestl

Which other coins have done this and I will add to the list?

None of these coins would run into this issue. If we had a single algo we would be good to go. We also are merged with BTC 0.14.0. As far as we know no one else is up to speed with that. LTC is not even fully on par with 0.13.

[TagBot]

[cryptmebro]

Don't fucking deploy Segregated Witness. Problem solved.

It's already causing more issues than it's worth. It's a technical piece of shit.

[HR]

Don't fucking deploy Segregated Witness. Problem solved.

It's already causing more issues than it's worth. It's a technical piece of shit.

And my question is whether DGB really even needs it at this time, and I have yet to see any forthright arguments explaining why it is, if it is.

[Danslip]

Don't fucking deploy Segregated Witness. Problem solved.

It's already causing more issues than it's worth. It's a technical piece of shit.

And my question is whether DGB really even needs it at this time, and I have yet to see any forthright arguments explaining why it is, if it is.

I think it will be good for DGB to get it working, the other coins that have enabled segwit don't have the marketing reach that Jared does, it will be good to create some much needed hype for dgb. I purchased quite a lot under 30 and I expect to see 80-90 on poloniex in short order.

[Altcoinfanatic]

Make a list of all the coins that have already done this bitcoin code base update and ask them for help. I can donate 5 btc.

1. Gulden
2. Litecoin
3. Groestl

Which other coins have done this and I will add to the list?

None of these coins would run into this issue. If we had a single algo we would be good to go. We also are merged with BTC 0.14.0. As far as we know no one else is up to speed with that. LTC is not even fully on par with 0.13.

Can't we just hardfork to segwit?
I just checked the merges of those 3 coins mentioned:

1. Gulden is on par with BTC 0.13.1
2. Litecoin is on par with BTC 0.13.2
3. Groestlcoin is partial on par with BTC 0.14.0 (same like Digibyte). Perhaps that is why they call it BTC 0.13.3

[Jumbley]

Anyway looks like they have overcome the issue, the reason we want segwit is introduce smart contracts to DigiByte!

Without any help or paying devs from any of those inferior projects, using our own devs that apparently don't know what they are doing but do a swell job of impersonating devs that do. Apparently! Great job DigiByte devs. 

[Investopedia]

That is good news.

Our community of devs deserve allot of credit for their hard work behind the scenes!

The new version is about allot more than just SegWit, it brings our code base up to par with the latest features in Bitcoin and adds the ability add features like faster transaction propagation and sync times, new algorithms, smart transactions and side chains...

It makes me excited to see all the new people joining in and contributing.

[Jumbley]

That is good news.

Our community of devs deserve allot of credit for their hard work behind the scenes!

The new version is about allot more than just SegWit, it brings our code base up to par with the latest features in Bitcoin and adds the ability add features like faster transaction propagation and sync times, new algorithms, smart transactions and side chains...

It makes me excited to see all the new people joining in and contributing.

indeed, this project and the people behind it are solid, the community is great and growing and digibyte is as cheap as chips. What more could anyone want?

[Geenstijl]

How much funds are left for development of Digibyte? They need another funding round I guess? They "only" had 250k which is nothing compared to the ICOs of the competition.

[Altcoinfanatic]

Without any help or paying devs from any of those inferior projects, using our own devs that apparently don't know what they are doing but do a swell job of impersonating devs that do. Apparently! Great job DigiByte devs. 

Are you saying Litecoin and Gulden are inferior? Why?
We should not celebrate so fast, you never know if we will hardfork like vertcoin did. Other devs will laugh at us if we hardfork.

[Jumbley]

Without any help or paying devs from any of those inferior projects, using our own devs that apparently don't know what they are doing but do a swell job of impersonating devs that do. Apparently! Great job DigiByte devs. 

Are you saying Litecoin and Gulden are inferior? Why?
We should not celebrate so fast, you never know if we will hardfork like vertcoin did. Other devs will laugh at us if we hardfork.

Look I've been around a bit, they laugh at us anyway, they never needed a good reason to do it.