No description, website, or topics provided.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.tx
build-aux/m4
contrib
depends
doc
qa
share
src
.gitattributes
.gitignore
.travis.yml
CHANGELOG.md
COPYING
INSTALL
Makefile.am
README.md
autogen.sh
configure.ac
gcoin-community.spec
libbitcoinconsensus.pc
libgcoinconsensus.pc.in

README.md

Copyright (c) 2014-2016 GCOIN Foundation

What is GCOIN?

GCOIN blockchain protocol is an open-source software. GCOIN is built for next-generation digital infrastructure, the distributed ledger.

For more information, see http://g-coin.org, or go to the help forum.

License

GCOIN is released under the terms of the Apache License 2.0. See COPYING for more information or see http://www.apache.org/licenses/LICENSE-2.0.html.

Development process

Developers work in their own trees, then submit pull requests when they think their feature or bug fix is ready.

If it is a simple/trivial/non-controversial change, then one of the GCOIN development team members simply pulls it.

The patch will be accepted if there is broad consensus that it is a good thing. Developers should expect to rework and resubmit patches if the code doesn't match the project's coding conventions (see doc/coding.md) or are controversial.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests 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

Manual Quality Assurance (QA) Testing

Large changes should have a test plan, and should be tested by somebody other than the developer who wrote the code.

Translations

Changes to translations as well as new translations can be submitted to support@g-coin.org

Development tips and tricks

compiling for debugging

Run configure with the --enable-debug option, then make. Or run configure with CXXFLAGS="-g -ggdb -O0" or whatever debug flags you need.

debug.log

If the code is behaving strangely, take a look in the debug.log file in the data directory; error and debugging message are written there.

The -debug=... command-line option controls debugging; running with just -debug will turn on all categories (and give you a very large debug.log file).

The Qt code routes qDebug() output to debug.log under category "qt": run with -debug=qt to see it.

testnet and regtest modes

Run with the -testnet option to run with "play bitcoins" on the test network, if you are testing multi-machine code that needs to operate across the internet.

If you are testing something that can run on one machine, run with the -regtest option. In regression test mode blocks can be created on-demand; see qa/rpc-tests/ for tests that run in -regest mode.

DEBUG_LOCKORDER

GCOIN Core is a multithreaded application, and deadlocks or other multithreading bugs can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of what locks are held, and adds warning to the debug.log file if inconsistencies are detected.

Help Forums

Post questions and get advice from other people using GCOIN.

https://groups.google.com/forum/#!forum/gcoins