Skip to content

Commit

Permalink
Updated README
Browse files Browse the repository at this point in the history 
This pull request updates the README.md file to follow MD formatting guidelines and strict linting rules.

Additionally, this pull request introduces a `Development Process` section which explains the DigiByte branching structure and methodology.

Finally, more precise language is introduced in the `Testing` section to highlight the necessity of including unit tests for all proposed code changes and the testing & validation process the should occur by the reviewer.
  • Loading branch information
@gto90
gto90 committed Mar 13, 2021
1 parent 135e35c commit 3b42f20
Showing 1 changed file with 68 additions and 73 deletions.
141 changes: 68 additions & 73 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,124 +1,119 @@
Development is now occurring on the DigiByte-Core repo
----------------
# Development is now occurring on the DigiByte-Core repo

As of 2020, development has now moved to the DigiByte-Core organization, under the digibyte repo

You can find more over at https://github.com/digibyte-core/digibyte
You can find more over at <https://github.com/digibyte-core/digibyte>

What is DigiByte?
----------------
## What is DigiByte?

DigiByte (DGB) is a rapidly growing decentralized, global blockchain that was founded in early 2014 with a focus on cyber security, payments & secure communications technologies.

For more information, as well as an immediately useable, binary version of the DigiByte Core software, see https://digibyte.io
For more information, as well as an immediately useable, binary version of the DigiByte Core software, see <https://digibyte.io>

## DigiByte FAQ

DigiByte FAQ
-------------
Launch Date: January 10th, 2014
**Launch Date**: January 10th, 2014

Blockchain Type: Public, Decentralized, UTXO based, Multi-Algorithm
**Blockchain Type**: Public, Decentralized, UTXO based, Multi-Algorithm

Ticker Symbol: DGB
**Ticker Symbol**: DGB

Genesis Block Hash: "USA Today: 10/Jan/2014, Target: Data stolen from up to 110M customers"
**Genesis Block Hash**: "USA Today: 10/Jan/2014, Target: Data stolen from up to 110M customers"

Max Total Supply: 21 Billion DigiBytes in 21 Years (2035)
**Max Total Supply**: 21 Billion DigiBytes in 21 Years (2035)

Current Supply: 11,692,747,373 DGB (April 2019)
**Current Supply**: 11,692,747,373 DGB (April 2019)

Block Reward Reduction: 1% Monthly
**Block Reward Reduction**: 1% Monthly

Current Block Reward: 688 DGB (April 2019)
**Current Block Reward**: 688 DGB (April 2019)

Mining Algorithms: Five individual: SHA256, Scrypt, Odocrypt, Skein & Qubit
**Mining Algorithms**: Five individual: SHA256, Scrypt, Odocrypt, Skein & Qubit

Block Interval: 15 Second Blocks (75 seconds per algo)
**Block Interval**: 15 Second Blocks (75 seconds per algo)

Algo Block Share: 20% Block Share Per Algo (5)
**Algo Block Share**: 20% Block Share Per Algo (5)

Difficulty Retarget: Every 1 Block, 5 Separate Difficulties, independent difficulty for each Mining Algo
**Difficulty Retarget**: Every 1 Block, 5 Separate Difficulties, independent difficulty for each Mining Algo

SegWit Support: Yes. First major altcoin to successfully activate Segwit. (April 2017)
**SegWit Support**: Yes. First major altcoin to successfully activate Segwit. (April 2017)

Hardforks: 4. DigiShield, MultiAlgo, MultiShield, DigiSpeed
**Hardforks**: 4. DigiShield, MultiAlgo, MultiShield, DigiSpeed

Softforks: 3. SegWit, CSV, NVersionBits
**Softforks**: 3. SegWit, CSV, NVersionBits

You can mine DigiByte on one of five separate mining algorithms. Each algo averages out to mine 20% of new blocks. This allows for much greater decentralization than other blockchains. An attacker with 99% of of any individual algorithm would still be unable to hardfork the blockchain, making DigiByte much more secure against PoW attacks than other blockchains.

DigiShield Hardfork: Block 67,200, Feb. 28th, 2014
**DigiShield Hardfork**: Block 67,200, Feb. 28th, 2014

**MultiAlgo Hardfork**: Block 145k, Sep. 1st 2014

**MultiShield Hardfork**: Block 400k, Dec. 10th 2014

**DigiSpeed Hardfork**: Block 1,430,000 Dec. 4th 2015

MultiAlgo Hardfork: Block 145k, Sep. 1st 2014
**Odocrypt Hardfork**: Block 9,112,320 July 22nd 2019

MultiShield Hardfork: Block 400k, Dec. 10th 2014
## DigiByte vs Bitcoin

DigiSpeed Hardfork: Block 1,430,000 Dec. 4th 2015
**Security**:

Odocrypt Hardfork: Block 9,112,320 July 22nd 2019
- 5 DigiByte mining algorithms vs. 1 Bitcoin mining algorithm.
- DigiByte mining is much more decentralized.
- DigiByte mining algorithms can be changed out in the future to prevent centralization.

DigiByte vs Bitcoin
-------------------
**Speed**:

Security: 5 DigiByte mining algorithms vs. 1 Bitcoin mining algorithm.
DigiByte mining is much more decentralized.
DigiByte mining algorithms can be changed out in the future to prevent centralization.
- DigiByte transactions occur much faster than Bitcoin transactions.
- 1-2 second transaction notifications.
- 15 second DigiByte blocks vs. 10 minute Bitcoin blocks.
- DigiByte has 6x block confirmations 1.5 minutes vs. 1 hour with Bitcoin.

Speed: DigiByte transactions occur much faster than Bitcoin transactions.
1-2 second transaction notifications.
15 second DigiByte blocks vs. 10 minute Bitcoin blocks.
DigiByte has 6x block confirmations 1.5 minutes vs. 1 hour with Bitcoin.
**Transaction Volume**:

Transaction Volume: DigiByte can handle many more transactions per second.
Bitcoin can only handle 3-4 transactions per second.
DigiByte currently can handle 560+ transactions per second.
The 2015 DigiSpeed hardfork introduced changes that double the capacity of the network every two years.
- DigiByte can handle many more transactions per second.
- Bitcoin can only handle 3-4 transactions per second.
- DigiByte currently can handle 560+ transactions per second.
- The 2015 DigiSpeed hardfork introduced changes that double the capacity of the network every two years.

Total Supply: More DigiBytes, lower price, more micro transactions, better price stability.
21 billion DigiBytes will be created over 21 years.
Only 21 million Bitcoin will be created over 140 years.
1000:1 ratio. 1000 DigiByte for every Bitcoin.
**Total Supply**:

Flexibility: Ability to quickly add new features.
DigiByte can add new features & upgrades much quicker than Bitcoin.
Future DigiByte upgrades will push transaction limit to several hundred thousand per second.
- More DigiBytes, lower price, more micro transactions, better price stability.
- 21 billion DigiBytes will be created over 21 years.
- Only 21 million Bitcoin will be created over 140 years.
- 1000:1 ratio. 1000 DigiByte for every Bitcoin.

Marketability & Usability: DigiByte is an easy brand to market to consumers.
DigiBytes are much cheaper to acquire.
**Flexibility**:

License
-------
- Ability to quickly add new features.
- DigiByte can add new features & upgrades much quicker than Bitcoin.
- Future DigiByte upgrades will push transaction limit to several hundred thousand per second.

DigiByte Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
information or see https://opensource.org/licenses/MIT.
**Marketability & Usability**:

Development Process
-------------------
- DigiByte is an easy brand to market to consumers.
- DigiBytes are much cheaper to acquire.

The `master` branch is regularly built and tested, but is not guaranteed to be
completely stable. [Tags](https://github.com/digibyte/digibyte/tags) are created
regularly to indicate new official, stable release versions of DigiByte Core.
## License

DigiByte Core is released under the terms of the MIT license. See [COPYING](COPYING) for more information or see <https://opensource.org/licenses/MIT>.

## Development Process

The `develop` branch is regularly built and tested, but is not guaranteed to be completely stable. Additionally, the develop branch represents ongoing development from which candidate releases will be cut. The `master` branch represents the current stable version currently in production. [Tags](https://github.com/digibyte/digibyte/tags) are created regularly to indicate new official, stable release versions of DigiByte Core. Finally, `feature/{a-new-feature}` branches represent current development destined for future releases.

The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).

Testing
-------
## Testing

### Automated Testing

Developers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: `make check`. Further details on running
and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
Developers are required to write [unit tests](src/test/README.md) for new code, and to submit new unit tests for any old code that is changed. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: `make check`. Further details on running and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).

There are also [regression and integration tests](/test), written
in Python, that are run automatically on the build server.
These tests can be run (if the [test dependencies](/test) are installed) with: `test/functional/test_runner.py`
There are also [regression and integration tests](/test), written in Python, that are run automatically on the build server. These tests can be run (if the [test dependencies](/test) are installed) with: `test/functional/test_runner.py`

The Travis CI system makes sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

### Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the
code. This is especially important for large or high-risk changes. It is useful
to add a test plan to the pull request description if testing the changes is
not straightforward.

Changes are required be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. A test plan must be included with the pull request description if testing the changes is not straightforward.

0 comments on commit 3b42f20

Please sign in to comment.