From b8c06ef409792dd9a6d14d46b50787fa7a6fb33d Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Fri, 13 Nov 2015 11:49:12 +0100 Subject: doc: Add non-style-related development guidelines I've collected these over time, mostly adding notes after troubleshooting obscure bugs. As I hope to get the community more involved in the whole process, I think it is useful to add to the developer-notes. --- doc/developer-notes.md | 169 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) (limited to 'doc') diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 7fe292f1f8..01eea931ad 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -204,3 +204,172 @@ If a set of tools is used by the build system or scripts the repository (for example, lcov) it is perfectly acceptable to add its files to `.gitignore` and commit them. +Development guidelines +============================ + +A few non-style-related recommendations for developers, as well as points to +pay attention to for reviewers of Bitcoin Core code. + +General Bitcoin Core +---------------------- + +- New features should be exposed on RPC first, then can be made available in the GUI + + - *Rationale*: RPC allows for better automatic testing. The test suite for + the GUI is very limited + +- Make sure pulls pass Travis CI before merging + + - *Rationale*: Makes sure that they pass thorough testing, and that the tester will keep passing + on the master branch. Otherwise all new pull requests will start failing the tests, resulting in + confusion and mayhem + + - *Explanation*: If the test suite is to be updated for a change, this has to + be done first + +Wallet +------- + +- Make sure that that no crashes happen with run-time option `-disablewallet`. + + - *Rationale*: In RPC code that conditionally use the wallet (such as + `validateaddress`) it is easy to forget that global pointer `pwalletMain` + can be NULL. See `qa/rpc-tests/disablewallet.py` for functional tests + exercising the API with `-disablewallet` + +- Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set + + - *Rationale*: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB + +General C++ +------------- + +- Assertions should not have side-effects + + - *Rationale*: Even though the source code is set to to refuse to compile + with assertions disabled, having side-effects in assertions is unexpected and + makes the code harder to understand + +- If you use the .h, you must link the .cpp + + - *Rationale*: Include files are the interface for the implementation file. Including one but + not linking the other is confusing. Please avoid that. Moving functions from + the `.h` to the `.cpp` should not result in build errors + +- Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example by using + `scoped_pointer` for allocations in a function. + + - *Rationale*: This avoids memory and resource leaks, and ensures exception safety + +C++ data structures +-------------------- + +- Never use the std::map [] syntax when reading from a map, but instead use .find() + + - *Rationale*: [] does an insert (of the default element) if the item doesn't + exist in the map yet. This has resulted in memory leaks in the past, as well as + race conditions (expecting read-read behavior). Using [] is fine for *writing* to a map + +- Do not compare an iterator from one data structure with an iterator of + another data structure (even if of the same type) + + - *Rationale*: Behavior is undefined. In C++ parlor this means "may reformat + the universe", in practice this has resulted in at least one hard-to-debug crash bug + +- Watch out for vector out-of-bounds exceptions. `&vch[0]` is illegal for an + empty vector, `&vch[vch.size()]` is always illegal. Use `begin_ptr(vch)` and + `end_ptr(vch)` to get the begin and end pointer instead (defined in + `serialize.h`) + +- Vector bounds checking is only enabled in debug mode. Do not rely on it + +- Make sure that constructors initialize all fields. If this is skipped for a + good reason (i.e., optimization on the critical path), add an explicit + comment about this + + - *Rationale*: Ensure determinism by avoiding accidental use of uninitialized + values. Also, static analyzers balk about this. + +- Use explicitly signed or unsigned `char`s, or even better `uint8_t` and + `int8_t`. Do not use bare `char` unless it is to pass to a third-party API. + This type can be signed or unsigned depending on the architecture, which can + lead to interoperability problems or dangerous conditions such as + out-of-bounds array accesses + +- Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior + + - *Rationale*: Easier to understand what is happening, thus easier to spot mistakes, even for those + that are not language lawyers + +Strings and formatting +------------------------ + +- Be careful of LogPrint versus LogPrintf. LogPrint takes a 'category' argument, LogPrintf does not. + + - *Rationale*: Confusion of these can result in runtime exceptions due to + formatting mismatch, and it is easy to get wrong because of subtly similar naming + +- Use std::string, avoid C string manipulation functions + + - *Rationale*: C++ string handling is marginally safer, less scope for + buffer overflows and surprises with \0 characters. Also some C string manipulations + tend to act differently depending on platform, or even the user locale + +- Use ParseInt32, ParseInt64, ParseDouble from `utilstrencodings.h` for number parsing + + - *Rationale*: These functions do overflow checking, and avoid pesky locale issues + +- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers + + - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion + +Threads and synchronization +---------------------------- + +- Build and run tests with `-DDEBUG_LOCKORDER` to verify that no potential + deadlocks are introduced. As of 0.12, this is defined by default when + configuring with `--enable-debug` + +- When using `LOCK`/`TRY_LOCK` be aware that the lock exists in the context of + the current scope, so surround the statement and the code that needs the lock + with braces + + OK: + +```c++ +{ + TRY_LOCK(cs_vNodes, lockNodes); + ... +} +``` + + Wrong: + +```c++ +TRY_LOCK(cs_vNodes, lockNodes); +{ + ... +} +``` + +Source code organization +-------------------------- + +- Implementation code should go into the `.cpp` file and not the `.h`, unless necessary due to template usage or + when performance due to inlining is critical + + - *Rationale*: Shorter and simpler header files are easier to read, and reduce compile time + +- Don't import anything into the global namespace (`using namespace ...`). Use + fully specified types such as `std::string`. + + - *Rationale*: Avoids symbol conflicts + +GUI +----- + +- Do not display or manipulate dialogs in model code (classes `*Model`) + + - *Rationale*: Model classes pass through events and data from the core, they + should not interact with the user. That's where View classes come in. The converse also + holds: try to not directly access core data structures from Views. -- cgit v1.2.3 From b171c69c6010271fe793db1f84897b5fbc6d8dc6 Mon Sep 17 00:00:00 2001 From: Michael Ford Date: Tue, 17 Nov 2015 22:14:36 +0800 Subject: [doc] Update OS X build notes for new qt5 configure You no longer need to explicitly pass qt5 to configure, as it will now choose qt5 over qt4 if both are installed. [skip-ci] --- doc/build-osx.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) (limited to 'doc') diff --git a/doc/build-osx.md b/doc/build-osx.md index 02498e5c4b..c3cb1b7891 100644 --- a/doc/build-osx.md +++ b/doc/build-osx.md @@ -5,7 +5,7 @@ This guide will show you how to build bitcoind (headless client) for OS X. Notes ----- -* Tested on OS X 10.7 through 10.10 on 64-bit Intel processors only. +* Tested on OS X 10.7 through 10.11 on 64-bit Intel processors only. * All of the commands should be executed in a Terminal application. The built-in one is located in `/Applications/Utilities`. @@ -24,7 +24,7 @@ be re-done or updated every time Xcode is updated. You will also need to install [Homebrew](http://brew.sh) in order to install library dependencies. -The installation of the actual dependencies is covered in the Instructions +The installation of the actual dependencies is covered in the instructions sections below. Instructions: Homebrew @@ -36,17 +36,19 @@ Instructions: Homebrew NOTE: Building with Qt4 is still supported, however, could result in a broken UI. As such, building with Qt5 is recommended. -### Building `bitcoind` +### Building `bitcoin` 1. Clone the GitHub tree to get the source code and go into the directory. git clone https://github.com/bitcoin/bitcoin.git cd bitcoin -2. Build bitcoind: +2. Build bitcoin-core: + This will configure and build the headless bitcoin binaries as well as the gui (if Qt is found). + You can disable the gui build by passing `--without-gui` to configure. ./autogen.sh - ./configure --with-gui=qt5 + ./configure make 3. It is also a good idea to build and run the unit tests: @@ -60,10 +62,10 @@ NOTE: Building with Qt4 is still supported, however, could result in a broken UI Use Qt Creator as IDE ------------------------ You can use Qt Creator as IDE, for debugging and for manipulating forms, etc. -Download Qt Creator from http://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process). +Download Qt Creator from https://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process). 1. Make sure you installed everything through Homebrew mentioned above -2. Do a proper ./configure --with-gui=qt5 --enable-debug +2. Do a proper ./configure --enable-debug 3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project 4. Enter "bitcoin-qt" as project name, enter src/qt as location 5. Leave the file selection as it is @@ -79,7 +81,7 @@ You can ignore this section if you are building `bitcoind` for your own use. bitcoind/bitcoin-cli binaries are not included in the Bitcoin-Qt.app bundle. -If you are building `bitcoind` or `Bitcoin-Qt` for others, your build machine should be set up +If you are building `bitcoind` or `Bitcoin Core` for others, your build machine should be set up as follows for maximum compatibility: All dependencies should be compiled with these flags: @@ -88,7 +90,7 @@ All dependencies should be compiled with these flags: -arch x86_64 -isysroot $(xcode-select --print-path)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin-Qt.app +Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin Core bundle is packaged and signed to create the .dmg disk image that is distributed. Running -- cgit v1.2.3 From cde857f2d977fbe3f96c093f6ca3c9810494191d Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Tue, 24 Nov 2015 10:27:38 -0500 Subject: Connect to Tor hidden services by default Adds 127.0.0.1:9050 for the .onion proxy if we can succesfully connect to the control port. Natural followup to creating hidden services automatically. --- doc/release-notes.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/release-notes.md b/doc/release-notes.md index 7db27f9fac..009baaed51 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -151,8 +151,8 @@ mining with the getblocktemplate protocol to a pool: this will affect you at the pool operator's discretion, which must be no later than BIP65 achieving its 951/1001 status. -Automatically listen on Tor ----------------------------- +Automatically use Tor hidden services +------------------------------------- Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket API, to create and destroy 'ephemeral' hidden services programmatically. @@ -160,8 +160,9 @@ Bitcoin Core has been updated to make use of this. This means that if Tor is running (and proper authorization is available), Bitcoin Core automatically creates a hidden service to listen on, without -manual configuration. This will positively affect the number of available -.onion nodes. +manual configuration. Bitcoin Core will also use Tor automatically to connect +to other .onion nodes if the control socket can be successfully opened. This +will positively affect the number of available .onion nodes and their usage. This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the `-listenonion`, -- cgit v1.2.3 From 49fb8e89b7036ea19a1275fc16bc0d2936619142 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sun, 29 Nov 2015 12:08:12 +0100 Subject: Documentation updates for BIP 130 --- doc/bips.md | 1 + doc/release-notes.md | 9 +++++++++ 2 files changed, 10 insertions(+) (limited to 'doc') diff --git a/doc/bips.md b/doc/bips.md index c780e2dde0..962b216123 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -18,3 +18,4 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**): * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)). * [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)). +* [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)). diff --git a/doc/release-notes.md b/doc/release-notes.md index 009baaed51..f7958381b6 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -206,6 +206,15 @@ Libsecp256k1 has undergone very extensive testing and validation. A side effect of this change is that libconsensus no longer depends on OpenSSL. +Direct headers announcement (BIP 130) +------------------------------------- + +Between compatible peers, BIP 130 direct headers announcement is used. This +means that blocks are advertized by announcing their headers directly, instead +of just announcing the hash. In a reorganization, all new headers are sent, +instead of just the new tip. This can often prevent an extra roundtrip before +the actual block is downloaded. + 0.12.0 Change log ================= -- cgit v1.2.3 From 9ac63d6d3056600c1b784da0e6b98f679fa98b6e Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Thu, 26 Nov 2015 18:42:07 +0100 Subject: Keep track of explicit wallet conflicts instead of using mempool --- doc/release-notes.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'doc') diff --git a/doc/release-notes.md b/doc/release-notes.md index f7958381b6..96c830d177 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -215,6 +215,24 @@ of just announcing the hash. In a reorganization, all new headers are sent, instead of just the new tip. This can often prevent an extra roundtrip before the actual block is downloaded. +Negative confirmations and conflict detection +--------------------------------------------- + +The wallet will now report a negative number for confirmations that indicates +how deep in the block chain the conflict is found. For example, if a transaction +A has 5 confirmations and spends the same input as a wallet transaction B, B +will be reported as having -5 confirmations. If another wallet transaction C +spends an output from B, it will also be reported as having -5 confirmations. +To detect conflicts with historical transactions in the chain a one-time +`-rescan` may be needed. + +Unlike earlier versions, unconfirmed but non-conflicting transactions will never +get a negative confirmation count. They are not treated as spendable unless +they're coming from ourself (change) and accepted into our local mempool, +however. The new "trusted" field in the `listtransactions` RPC output +indicates whether outputs of an unconfirmed transaction are considered +spendable. + 0.12.0 Change log ================= -- cgit v1.2.3 From fad3035e8d84dd3cbd166b9722127da373d34554 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Mon, 23 Nov 2015 21:11:53 +0100 Subject: [doc] Minor markdown fixes --- doc/developer-notes.md | 24 ++++++++++++------------ doc/unit-tests.md | 10 +++++----- 2 files changed, 17 insertions(+), 17 deletions(-) (limited to 'doc') diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 01eea931ad..358792251b 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -218,7 +218,7 @@ General Bitcoin Core - *Rationale*: RPC allows for better automatic testing. The test suite for the GUI is very limited -- Make sure pulls pass Travis CI before merging +- Make sure pull requests pass Travis CI before merging - *Rationale*: Makes sure that they pass thorough testing, and that the tester will keep passing on the master branch. Otherwise all new pull requests will start failing the tests, resulting in @@ -230,9 +230,9 @@ General Bitcoin Core Wallet ------- -- Make sure that that no crashes happen with run-time option `-disablewallet`. +- Make sure that no crashes happen with run-time option `-disablewallet`. - - *Rationale*: In RPC code that conditionally use the wallet (such as + - *Rationale*: In RPC code that conditionally uses the wallet (such as `validateaddress`) it is easy to forget that global pointer `pwalletMain` can be NULL. See `qa/rpc-tests/disablewallet.py` for functional tests exercising the API with `-disablewallet` @@ -250,9 +250,9 @@ General C++ with assertions disabled, having side-effects in assertions is unexpected and makes the code harder to understand -- If you use the .h, you must link the .cpp +- If you use the `.h`, you must link the `.cpp` - - *Rationale*: Include files are the interface for the implementation file. Including one but + - *Rationale*: Include files define the interface for the code in implementation files. Including one but not linking the other is confusing. Please avoid that. Moving functions from the `.h` to the `.cpp` should not result in build errors @@ -264,11 +264,11 @@ General C++ C++ data structures -------------------- -- Never use the std::map [] syntax when reading from a map, but instead use .find() +- Never use the `std::map []` syntax when reading from a map, but instead use `.find()` - - *Rationale*: [] does an insert (of the default element) if the item doesn't + - *Rationale*: `[]` does an insert (of the default element) if the item doesn't exist in the map yet. This has resulted in memory leaks in the past, as well as - race conditions (expecting read-read behavior). Using [] is fine for *writing* to a map + race conditions (expecting read-read behavior). Using `[]` is fine for *writing* to a map - Do not compare an iterator from one data structure with an iterator of another data structure (even if of the same type) @@ -304,18 +304,18 @@ C++ data structures Strings and formatting ------------------------ -- Be careful of LogPrint versus LogPrintf. LogPrint takes a 'category' argument, LogPrintf does not. +- Be careful of `LogPrint` versus `LogPrintf`. `LogPrint` takes a `category` argument, `LogPrintf` does not. - *Rationale*: Confusion of these can result in runtime exceptions due to formatting mismatch, and it is easy to get wrong because of subtly similar naming -- Use std::string, avoid C string manipulation functions +- Use `std::string`, avoid C string manipulation functions - *Rationale*: C++ string handling is marginally safer, less scope for - buffer overflows and surprises with \0 characters. Also some C string manipulations + buffer overflows and surprises with `\0` characters. Also some C string manipulations tend to act differently depending on platform, or even the user locale -- Use ParseInt32, ParseInt64, ParseDouble from `utilstrencodings.h` for number parsing +- Use `ParseInt32`, `ParseInt64`, `ParseDouble` from `utilstrencodings.h` for number parsing - *Rationale*: These functions do overflow checking, and avoid pesky locale issues diff --git a/doc/unit-tests.md b/doc/unit-tests.md index 72613054b9..afaece829c 100644 --- a/doc/unit-tests.md +++ b/doc/unit-tests.md @@ -1,18 +1,18 @@ Compiling/running unit tests ------------------------------------ -Unit tests will be automatically compiled if dependencies were met in configure +Unit tests will be automatically compiled if dependencies were met in `./configure` and tests weren't explicitly disabled. -After configuring, they can be run with 'make check'. +After configuring, they can be run with `make check`. -To run the bitcoind tests manually, launch src/test/test_bitcoin . +To run the bitcoind tests manually, launch `src/test/test_bitcoin`. To add more bitcoind tests, add `BOOST_AUTO_TEST_CASE` functions to the existing -.cpp files in the test/ directory or add new .cpp files that +.cpp files in the `test/` directory or add new .cpp files that implement new BOOST_AUTO_TEST_SUITE sections. -To run the bitcoin-qt tests manually, launch src/qt/test/test_bitcoin-qt +To run the bitcoin-qt tests manually, launch `src/qt/test/test_bitcoin-qt` To add more bitcoin-qt tests, add them to the `src/qt/test/` directory and the `src/qt/test/test_main.cpp` file. -- cgit v1.2.3 From b4404090259be4e34ef5dba33e47a41e7d9acc03 Mon Sep 17 00:00:00 2001 From: Matt Bogosian Date: Tue, 1 Dec 2015 22:49:51 -0800 Subject: Add missing automake package to deb-based UNIX install instructions. --- doc/build-unix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/build-unix.md b/doc/build-unix.md index 159a140608..31bbab7f0f 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -61,7 +61,7 @@ Dependency Build Instructions: Ubuntu & Debian ---------------------------------------------- Build requirements: - sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libevent-dev bsdmainutils + sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils On at least Ubuntu 14.04+ and Debian 7+ there are generic names for the individual boost development packages, so the following can be used to only -- cgit v1.2.3 From 93236c0455ded01f1af5d28f8be0801120a18ff2 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Wed, 2 Dec 2015 14:28:35 +0100 Subject: qt: Final translation update before 0.12 fork - Add new translations (finally, after a long time) - update-translation script was not considering new translations - oops - fixed this, also remove (nearly) empty translations - Update translation process, it was still describing the old repository structure --- doc/translation_process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/translation_process.md b/doc/translation_process.md index 6389c5aced..310d560b36 100644 --- a/doc/translation_process.md +++ b/doc/translation_process.md @@ -74,10 +74,10 @@ The Transifex Bitcoin project config file is included as part of the repo. It ca To assist in updating translations, we have created a script to help. 1. `python contrib/devtools/update-translations.py` -2. Update `src/qt/bitcoin.qrc` manually or via +2. Update `src/qt/bitcoin_locale.qrc` manually or via `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/locale\/\1.qm<\/file>/'` -3. Update `src/qt/Makefile.am` manually or via - `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ locale\/\1.ts \\/'` +3. Update `src/Makefile.qt.include` manually or via + `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ qt\/locale\/\1.ts \\/'` 4. `git add` new translations from `src/qt/locale/` **Do not directly download translations** one by one from the Transifex website, as we do a few post-processing steps before committing the translations. -- cgit v1.2.3 From 8a03727d9cc975a3d0843d83ef05957b9e9fbbca Mon Sep 17 00:00:00 2001 From: paveljanik Date: Fri, 3 Jul 2015 16:36:49 +0200 Subject: Fix various typos --- doc/release-notes/release-notes-0.6.3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/release-notes/release-notes-0.6.3.md b/doc/release-notes/release-notes-0.6.3.md index 28bb20e104..c27f607b5c 100644 --- a/doc/release-notes/release-notes-0.6.3.md +++ b/doc/release-notes/release-notes-0.6.3.md @@ -23,7 +23,7 @@ hundreds of blocks long. Bitcoin-Qt no longer automatically selects the first address in the address book (Issue #1384). -Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac. +Fixed minimize-to-dock behavior of Bitcoin-Qt on the Mac. Added a block checkpoint at block 185,333 to speed up initial blockchain download. -- cgit v1.2.3 From c12ff995f7d70aafb12f34887fb64aa7482bbc85 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Thu, 3 Dec 2015 11:59:37 +0100 Subject: Now that 0.12 has been branched, master is 0.12.99 ... in preparation for 0.13 --- doc/Doxyfile | 2 +- doc/README.md | 2 +- doc/README_windows.txt | 2 +- doc/release-notes.md | 268 +------------------------------------------------ 4 files changed, 6 insertions(+), 268 deletions(-) (limited to 'doc') diff --git a/doc/Doxyfile b/doc/Doxyfile index 925a33ee89..428fba98e1 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -34,7 +34,7 @@ PROJECT_NAME = Bitcoin # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = 0.11.99 +PROJECT_NUMBER = 0.12.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer diff --git a/doc/README.md b/doc/README.md index f6df28a89b..c0f9ee5220 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99 +Bitcoin Core 0.12.99 ===================== Setup diff --git a/doc/README_windows.txt b/doc/README_windows.txt index e4fd9bdf90..2d1c4503c9 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99 +Bitcoin Core 0.12.99 ===================== Intro diff --git a/doc/release-notes.md b/doc/release-notes.md index 96c830d177..8bb842ddb8 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -4,236 +4,11 @@ release-notes at release time) Notable changes =============== -SSL support for RPC dropped ----------------------------- +Example item +---------------- -SSL support for RPC, previously enabled by the option `rpcssl` has been dropped -from both the client and the server. This was done in preparation for removing -the dependency on OpenSSL for the daemon completely. -Trying to use `rpcssl` will result in an error: - - Error: SSL mode for RPC (-rpcssl) is no longer supported. - -If you are one of the few people that relies on this feature, a flexible -migration path is to use `stunnel`. This is an utility that can tunnel -arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with: - - sudo apt-get install stunnel4 - -Then, to tunnel a SSL connection on 28332 to a RPC server bound on localhost on port 18332 do: - - stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P '' - -It can also be set up system-wide in inetd style. - -Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution -would allow the use of different authentication, loadbalancing, on-the-fly compression and -caching. A sample config for apache2 could look like: - - Listen 443 - - NameVirtualHost *:443 - - - SSLEngine On - SSLCertificateFile /etc/apache2/ssl/server.crt - SSLCertificateKeyFile /etc/apache2/ssl/server.key - - - ProxyPass http://127.0.0.1:8332/ - ProxyPassReverse http://127.0.0.1:8332/ - # optional enable digest auth - # AuthType Digest - # ... - - # optional bypass bitcoind rpc basic auth - # RequestHeader set Authorization "Basic " - # get the from the shell with: base64 <<< bitcoinrpc: - - - # Or, balance the load: - # ProxyPass / balancer://balancer_cluster_name - - - -Random-cookie RPC authentication ---------------------------------- - -When no `-rpcpassword` is specified, the daemon now uses a special 'cookie' -file for authentication. This file is generated with random content when the -daemon starts, and deleted when it exits. Its contents are used as -authentication token. Read access to this file controls who can access through -RPC. By default it is stored in the data directory but its location can be -overridden with the option `-rpccookiefile`. - -This is similar to Tor's CookieAuthentication: see -https://www.torproject.org/docs/tor-manual.html.en - -This allows running bitcoind without having to do any manual configuration. - -Low-level RPC API changes --------------------------- - -- Monetary amounts can be provided as strings. This means that for example the - argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an - advantage if a JSON library insists on using a lossy floating point type for - numbers, which would be dangerous for monetary amounts. - -Option parsing behavior ------------------------ - -Command line options are now parsed strictly in the order in which they are -specified. It used to be the case that `-X -noX` ends up, unintuitively, with X -set, as `-X` had precedence over `-noX`. This is no longer the case. Like for -other software, the last specified value for an option will hold. - -`NODE_BLOOM` service bit ------------------------- - -Support for the `NODE_BLOOM` service bit, as described in [BIP -111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been -added to the P2P protocol code. - -BIP 111 defines a service bit to allow peers to advertise that they support -bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol -version to allow peers to identify old nodes which allow bloom filtering of the -connection despite lacking the new service bit. - -In this version, it is only enforced for peers that send protocol versions -`>=70011`. For the next major version it is planned that this restriction will be -removed. It is recommended to update SPV clients to check for the `NODE_BLOOM` -service bit for nodes that report versions newer than 70011. - -Any sequence of pushdatas in OP_RETURN outputs now allowed ----------------------------------------------------------- - -Previously OP_RETURN outputs with a payload were only relayed and mined if they -had a single pushdata. This restriction has been lifted to allow any -combination of data pushes and numeric constant opcodes (OP_1 to OP_16). The -limit on OP_RETURN output size is now applied to the entire serialized -scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three -bytes overhead) - -Merkle branches removed from wallet ------------------------------------ - -Previously, every wallet transaction stored a Merkle branch to prove its -presence in blocks. This wasn't being used for more than an expensive -sanity check. Since 0.12, these are no longer stored. When loading a -0.12 wallet into an older version, it will automatically rescan to avoid -failed checks. - -BIP65 - CHECKLOCKTIMEVERIFY ---------------------------- - -Previously it was impossible to create a transaction output that was guaranteed -to be unspendable until a specific date in the future. CHECKLOCKTIMEVERIFY is a -new opcode that allows a script to check if a specific block height or time has -been reached, failing the script otherwise. This enables a wide variety of new -functionality such as time-locked escrows, secure payment channels, etc. - -BIP65 implements CHECKLOCKTIMEVERIFY by introducing block version 4, which adds -additional restrictions to the NOP2 opcode. The same miner-voting mechanism as -in BIP34 and BIP66 is used: when 751 out of a sequence of 1001 blocks have -version number 4 or higher, the new consensus rule becomes active for those -blocks. When 951 out of a sequence of 1001 blocks have version number 4 or -higher, it becomes mandatory for all blocks and blocks with versions less than -4 are rejected. - -Bitcoin Core's block templates are now for version 4 blocks only, and any -mining software relying on its `getblocktemplate` must be updated in parallel -to use either libblkmaker version 0.4.3 or any version from 0.5.2 onward. If -you are solo mining, this will affect you the moment you upgrade Bitcoin Core, -which must be done prior to BIP65 achieving its 951/1001 status. If you are -mining with the stratum mining protocol: this does not affect you. If you are -mining with the getblocktemplate protocol to a pool: this will affect you at -the pool operator's discretion, which must be no later than BIP65 achieving its -951/1001 status. - -Automatically use Tor hidden services -------------------------------------- - -Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket -API, to create and destroy 'ephemeral' hidden services programmatically. -Bitcoin Core has been updated to make use of this. - -This means that if Tor is running (and proper authorization is available), -Bitcoin Core automatically creates a hidden service to listen on, without -manual configuration. Bitcoin Core will also use Tor automatically to connect -to other .onion nodes if the control socket can be successfully opened. This -will positively affect the number of available .onion nodes and their usage. - -This new feature is enabled by default if Bitcoin Core is listening, and -a connection to Tor can be made. It can be configured with the `-listenonion`, -`-torcontrol` and `-torpassword` settings. To show verbose debugging -information, pass `-debug=tor`. - -Reduce upload traffic ---------------------- - -A major part of the outbound traffic is caused by serving historic blocks to -other nodes in initial block download state. - -It is now possible to reduce the total upload traffic via the `-maxuploadtarget` -parameter. This is *not* a hard limit but a threshold to minimize the outbound -traffic. When the limit is about to be reached, the uploaded data is cut by not -serving historic blocks (blocks older than one week). -Moreover, any SPV peer is disconnected when they request a filtered block. - -This option can be specified in MiB per day and is turned off by default -(`-maxuploadtarget=0`). -The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day. - -Whitelisted peers will never be disconnected, although their traffic counts for -calculating the target. - -A more detailed documentation about keeping traffic low can be found in -[/doc/reducetraffic.md](/doc/reducetraffic.md). - -Signature validation using libsecp256k1 ---------------------------------------- - -ECDSA signatures inside Bitcoin transactions now use validation using -[https://github.com/bitcoin/secp256k1](libsecp256k1) instead of OpenSSL. - -Depending on the platform, this means a significant speedup for raw signature -validation speed. The advantage is largest on x86_64, where validation is over -five times faster. In practice, this translates to a raw reindexing and new -block validation times that are less than half of what it was before. - -Libsecp256k1 has undergone very extensive testing and validation. - -A side effect of this change is that libconsensus no longer depends on OpenSSL. - -Direct headers announcement (BIP 130) -------------------------------------- - -Between compatible peers, BIP 130 direct headers announcement is used. This -means that blocks are advertized by announcing their headers directly, instead -of just announcing the hash. In a reorganization, all new headers are sent, -instead of just the new tip. This can often prevent an extra roundtrip before -the actual block is downloaded. - -Negative confirmations and conflict detection ---------------------------------------------- - -The wallet will now report a negative number for confirmations that indicates -how deep in the block chain the conflict is found. For example, if a transaction -A has 5 confirmations and spends the same input as a wallet transaction B, B -will be reported as having -5 confirmations. If another wallet transaction C -spends an output from B, it will also be reported as having -5 confirmations. -To detect conflicts with historical transactions in the chain a one-time -`-rescan` may be needed. - -Unlike earlier versions, unconfirmed but non-conflicting transactions will never -get a negative confirmation count. They are not treated as spendable unless -they're coming from ourself (change) and accepted into our local mempool, -however. The new "trusted" field in the `listtransactions` RPC output -indicates whether outputs of an unconfirmed transaction are considered -spendable. - -0.12.0 Change log +0.13.0 Change log ================= Detailed release notes follow. This overview includes changes that affect @@ -243,33 +18,6 @@ git merge commit are mentioned. ### RPC and REST -Asm representations of scriptSig signatures now contain SIGHASH type decodes ----------------------------------------------------------------------------- - -The `asm` property of each scriptSig now contains the decoded signature hash -type for each signature that provides a valid defined hash type. - -The following items contain assembly representations of scriptSig signatures -and are affected by this change: - -- RPC `getrawtransaction` -- RPC `decoderawtransaction` -- REST `/rest/tx/` (JSON format) -- REST `/rest/block/` (JSON format when including extended tx details) -- `bitcoin-tx -json` - -For example, the `scriptSig.asm` property of a transaction input that -previously showed an assembly representation of: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 - -now shows as: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] - -Note that the output of the RPC `decodescript` did not change because it is -configured specifically to process scriptPubKey and not scriptSig scripts. - ### Configuration and command-line options ### Block and transaction handling @@ -288,13 +36,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts. ### Miscellaneous -- Removed bitrpc.py from contrib - -Addition of ZMQ-based Notifications -================================== - -Bitcoind can now (optionally) asynchronously notify clients through a -ZMQ-based PUB socket of the arrival of new transactions and blocks. -This feature requires installation of the ZMQ C API library 4.x and -configuring its use through the command line or configuration file. -Please see docs/zmq.md for details of operation. -- cgit v1.2.3 From 37d271d7cce44885f835292ffe99b54399b014d6 Mon Sep 17 00:00:00 2001 From: mb300sd Date: Mon, 14 Dec 2015 14:21:34 -0500 Subject: Rename OP_NOP2 to OP_CHECKLOCKTIMEVERIFY. --- doc/release-notes.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'doc') diff --git a/doc/release-notes.md b/doc/release-notes.md index 8bb842ddb8..801b684e6b 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -18,6 +18,20 @@ git merge commit are mentioned. ### RPC and REST +Asm script outputs now contain OP_CHECKLOCKTIMEVERIFY in place of OP_NOP2 +------------------------------------------------------------------------- + +OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP +65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) + +The following outputs are affected by this change: +- RPC `getrawtransaction` (in verbose mode) +- RPC `decoderawtransaction` +- RPC `decodescript` +- REST `/rest/tx/` (JSON format) +- REST `/rest/block/` (JSON format when including extended tx details) +- `bitcoin-tx -json` + ### Configuration and command-line options ### Block and transaction handling -- cgit v1.2.3 From d570a1f41b9eef60db441be0eb26c9f5020e3c6a Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 9 Jan 2016 17:40:39 +0000 Subject: doc/bips: Document BIP 125 support --- doc/bips.md | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/bips.md b/doc/bips.md index 962b216123..e73add0130 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -18,4 +18,5 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**): * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)). * [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)). +* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). * [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)). -- cgit v1.2.3 From 99fda26de0661afcbe43d5e862c382e3c2e3aa5e Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Thu, 19 Nov 2015 13:11:50 +0100 Subject: doc: Make networking work inside builder in gitian-building.md These are changes I needed to get gitian building to work with Debian 8.2, which is the version we tell to use. - Set up NAT, so that container can access network beyond host - Remove explicit cgroup setup - these are mounted automatically now --- doc/gitian-building.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/gitian-building.md b/doc/gitian-building.md index 019e851696..dd98c038a5 100644 --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -262,12 +262,12 @@ Then set up LXC and the rest with the following, which is a complex jumble of se # the version of lxc-start in Debian 7.4 needs to run as root, so make sure # that the build script can execute it without providing a password echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc -# add cgroup for LXC -echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab # make /etc/rc.local script that sets up bridge between guest and host echo '#!/bin/sh -e' > /etc/rc.local echo 'brctl addbr br0' >> /etc/rc.local echo 'ifconfig br0 10.0.3.2/24 up' >> /etc/rc.local +echo 'iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE' >> /etc/rc.local +echo 'echo 1 > /proc/sys/net/ipv4/ip_forward' >> /etc/rc.local echo 'exit 0' >> /etc/rc.local # make sure that USE_LXC is always set when logging in as debian, # and configure LXC IP addresses -- cgit v1.2.3 From 3b468a0e609147c7d7afd8ed97bf271f2356daef Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Thu, 19 Nov 2015 13:25:08 +0100 Subject: gitian: Need `ca-certificates` and `python` for LXC builds --- doc/gitian-building.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/gitian-building.md b/doc/gitian-building.md index dd98c038a5..e3fb944388 100644 --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -259,7 +259,7 @@ adduser debian sudo Then set up LXC and the rest with the following, which is a complex jumble of settings and workarounds: ```bash -# the version of lxc-start in Debian 7.4 needs to run as root, so make sure +# the version of lxc-start in Debian needs to run as root, so make sure # that the build script can execute it without providing a password echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc # make /etc/rc.local script that sets up bridge between guest and host -- cgit v1.2.3 From c6325cf2f964f86d0490a59eeb3ccaa6f899238d Mon Sep 17 00:00:00 2001 From: Paul Rabahy Date: Mon, 25 Jan 2016 19:39:46 -0500 Subject: Minor improvements to the release process Instruct people to "git fetch" so that if this is their 2nd+ gitian build they will have a fresh bitcoin repo. Instruct people to add all the known pgp keys to their keyring so that gverify will print more useful info. --- doc/release-process.md | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) (limited to 'doc') diff --git a/doc/release-process.md b/doc/release-process.md index 9a2362cb85..39e3032a67 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -41,6 +41,7 @@ Check out the source code in the following directory hierarchy. pushd ./bitcoin export SIGNER=(your Gitian key, ie bluematt, sipa, etc) export VERSION=(new version, e.g. 0.8.0) + git fetch git checkout v${VERSION} popd @@ -83,25 +84,16 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from ``` The gbuild invocations below DO NOT DO THIS by default. -###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X: +###Build and Sign Bitcoin Core for Linux, Windows, and OS X: ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml - mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../ ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml - mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz - mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../ ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml - mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz - mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../ - popd Build output expected: @@ -111,6 +103,27 @@ The gbuild invocations below DO NOT DO THIS by default. 4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz) 5. Gitian signatures (in gitian.sigs/${VERSION}-/(your Gitian key)/ +###Verify other gitian builders signatures to your own. (Optional) + + Add other gitian builders keys to your gpg keyring + + gpg --import ../bitcoin/contrib/gitian-downloader/*.pgp + + Verify the signatures + + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml + +###Move the outputs to the correct directory + + mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../ + mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz + mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../ + mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz + mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../ + popd + ###Next steps: Commit your signature to gitian.sigs: -- cgit v1.2.3 From f9298cc60e093533ce109aedd7d54d59e87865cd Mon Sep 17 00:00:00 2001 From: Jarret Dyrbye Date: Wed, 27 Jan 2016 20:17:02 -0700 Subject: doc: add example for building with constrained resources discussed in github issue #6658 --- doc/build-unix.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/build-unix.md b/doc/build-unix.md index 31bbab7f0f..943bfadb91 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -50,12 +50,15 @@ Optional dependencies: For the versions used in the release, see [release-process.md](release-process.md) under *Fetch and build inputs*. -System requirements +Memory Requirements -------------------- -C++ compilers are memory-hungry. It is recommended to have at least 1 GB of -memory available when compiling Bitcoin Core. With 512MB of memory or less -compilation will take much longer due to swap thrashing. +C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of +memory available when compiling Bitcoin Core. On systems with less, gcc can be +tuned to conserve memory with additional CXXFLAGS: + + + ./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768" Dependency Build Instructions: Ubuntu & Debian ---------------------------------------------- -- cgit v1.2.3 From befeb554184682ac9d98b56ef4e7f20642be01d0 Mon Sep 17 00:00:00 2001 From: Nathaniel Mahieu Date: Thu, 28 Jan 2016 11:10:15 -0600 Subject: Add example for displaying additional configure flags --- doc/build-unix.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc') diff --git a/doc/build-unix.md b/doc/build-unix.md index 31bbab7f0f..1121a3507f 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -236,3 +236,9 @@ In this case there is no dependency on Berkeley DB 4.8. Mining is also possible in disable-wallet mode, but only using the `getblocktemplate` RPC call not `getwork`. + +Additional Configure Flags +-------------------------- +A list of additional configure flags can be displayed with: + + ./configure --help -- cgit v1.2.3 From 666a0f835aa9c3a608810e014d315b90a44c8f62 Mon Sep 17 00:00:00 2001 From: fanquake Date: Sat, 30 Jan 2016 10:10:11 +0800 Subject: Use Debian 8.3 in gitian build guide Add instructions to clone the gitian.sigs repo --- doc/gitian-building.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/gitian-building.md b/doc/gitian-building.md index e3fb944388..5ca91505e7 100644 --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -74,11 +74,11 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the - File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side - Click `Create` -Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/debian-8.2.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)). +Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)). This DVD image can be validated using a SHA256 hashing tool, for example on Unixy OSes by entering the following in a terminal: - echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c + echo "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654 debian-8.3.0-amd64-netinst.iso" | sha256sum -c # (must return OK) After creating the VM, we need to configure it. @@ -305,6 +305,7 @@ Clone the git repositories for bitcoin and Gitian. ```bash git clone https://github.com/devrandom/gitian-builder.git git clone https://github.com/bitcoin/bitcoin +git clone https://github.com/bitcoin/gitian.sigs.git ``` Setting up the Gitian image -- cgit v1.2.3