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.
Topic: ★★DigiByte|极特币★★[DGB]✔ Core v6.16.5.1 - DigiShield, DigiSpeed, Segwit - page 361. (Read 3059029 times)
April 06, 2017, 04:52:21 AM
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.
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.
April 06, 2017, 04:29:30 AM
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.1. Gulden
2. Litecoin
3. Groestl
Which other coins have done this and I will add to the list?
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
April 06, 2017, 04:28:07 AM
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.
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.
April 06, 2017, 03:38:55 AM
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.
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.
April 05, 2017, 07:57:06 PM
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.
It's already causing more issues than it's worth. It's a technical piece of shit.
April 05, 2017, 01:37:25 PM
April 05, 2017, 11:25:29 AM
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. 1. Gulden
2. Litecoin
3. Groestl
Which other coins have done this and I will add to the list?
April 05, 2017, 11:15:29 AM
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?
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.
April 05, 2017, 10:56:22 AM
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?
1. Gulden
2. Litecoin
3. Groestl
Which other coins have done this and I will add to the list?
April 05, 2017, 09:45:59 AM
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
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
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
When mining through a test network and all the phases here are the block versions we are getting converted to binary and hex:
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
Code:
enum ThresholdState {
THRESHOLD_DEFINED,
THRESHOLD_STARTED,
THRESHOLD_LOCKED_IN,
THRESHOLD_ACTIVE,
THRESHOLD_FAILED,
};
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;
/** 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),
};
{
// 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
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.
April 05, 2017, 08:10:53 AM
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
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
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
When mining through a test network and all the phases here are the block versions we are getting converted to binary and hex:
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
Code:
enum ThresholdState {
THRESHOLD_DEFINED,
THRESHOLD_STARTED,
THRESHOLD_LOCKED_IN,
THRESHOLD_ACTIVE,
THRESHOLD_FAILED,
};
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;
/** 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),
};
{
// 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
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
April 05, 2017, 06:25:21 AM
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.”
“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.”
April 04, 2017, 12:47:30 PM
When is DGB Gaming Back?
and please watch your gramma!
Quote
We are pausing all payouts until we fix some issues with exploits in payout API interface. Than you for your understanding.
ThanK you!
April 04, 2017, 05:14:52 AM
I fricking love loading up on DGB
Haha same here man! Don't miss the GAME train though!!
April 03, 2017, 10:04:01 PM
I fricking love loading up on DGB
April 03, 2017, 05:59:33 PM
Hello, please how can I transfer my DGB paper wallet created on website: https://walletgenerator.net/?currency=DigiByte to my digibyte wallet on my PC?
1. Core wallet
2. Help
3. Debugwindow
4. console
5. importprivkey "digibyteprivkey" ( "label" ) ( rescan )
That’s my best guess!
April 03, 2017, 03:55:16 PM
Hello, please how can I transfer my DGB paper wallet created on website: https://walletgenerator.net/?currency=DigiByte to my digibyte wallet on my PC?
April 03, 2017, 11:31:11 AM
All solid coins are rising. i think DGB has potential. Bought a small stake.
April 03, 2017, 07:44:48 AM
How high can we go this time?
March 31, 2017, 11:49:12 AM
I understand that DGB is trying to activate segwit.. where can I see the progress of signalling ?
You can't see that just yet because DigiByte 6.14.1 has not been set free into the wild just yet. a dirty copy of it is being tested within the community so keep watching this space, news will be posted here, if I know about it. "Just a quick update for everyone, we are working through a slight mining bug in one of the algos during soft fork process. This doesn't effect any normal wallet functions in test wallet released. Once we are 100% confident in a smooth transition we will do an official release of 6.14.1. Thank you to all those helping us test!"
Jump to: