5ad80bec3f
3d9b41ecc0build: add --enable-determinism configure flag (fanquake) Pull request description: This adds a `--enable-determinsm` configure flag, which if used, will enable additional compile / link time flags to make subsequent builds of bitcoind deterministic. The first flag enabled is `--no-insert-timestamp`. This prevents the linker from embedding timestamps, and makes consecutive builds of `bitcoind.exe` deterministic. This will likely also be used for [Guix Windows builds](https://github.com/bitcoin/bitcoin/pull/17595#issuecomment-582696467). [`--no-insert-timestamp`](https://manpages.debian.org/buster/binutils-mingw-w64-x86-64/x86_64-w64-mingw32-ld.bfd.1.en.html): > The option --no-insert-timestamp can be used to insert a zero value for the timestamp, this ensuring that binaries produced from identical sources will compare identically. Diff of consecutive builds of [master](2bdc476d4d): ```diff --- bitcoind.exe.1 +++ bitcoind.exe.2 @@ -2,20 +2,20 @@ 00000060: 7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS 00000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$....... -00000080: 5045 0000 6486 1400 57e8 445e 00da 6900 PE..d...W.D^..i. +00000080: 5045 0000 6486 1400 e3e9 445e 00da 6900 PE..d.....D^..i.00000090: e015 0100 f000 2600 0b02 021f 00de 4900 ......&.......I. 000000a0: 00b0 5b00 008a 0000 e014 0000 0010 0000 ..[............. 000000b0: 0000 4000 0000 0000 0010 0000 0002 0000 ..@............. 000000c0: 0400 0000 0000 0000 0500 0200 0000 0000 ................ -000000d0: 00f0 6a00 0006 0000 bd31 af00 0300 6001 ..j......1....`. +000000d0: 00f0 6a00 0006 0000 d434 af00 0300 6001 ..j......4....`. 000000e0: 0000 2000 0000 0000 0010 0000 0000 0000 .. ............. @@ -373594,15 +373594,15 @@ 005b35f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -005b3600: 0000 0000 57e8 445e 0000 0000 7ce1 5b00 ....W.D^....|.[. +005b3600: 0000 0000 e2e9 445e 0000 0000 7ce1 5b00 ......D^....|.[. 005b3610: 0100 0000 2200 0000 2200 0000 28e0 5b00 ...."..."...(.[. ``` ACKs for top commit: practicalswift: ACK3d9b41ecc0-- patch looks correct laanwj: ACK3d9b41ecc0Tree-SHA512: 1ff9dab7fa818b1fc6b0eb3b7a1e0468aac9e2578f4451aa300a648f883fa83f83722067f1adf27ebad54157790857d1501d573adbd7ebdf6962858cc669960d
Bitcoin Core integration/staging tree
What is Bitcoin?
Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.
For more information, as well as an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/, or read the original whitepaper.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
Development Process
The master branch is regularly built and tested, but is not guaranteed to be
completely stable. Tags are created
regularly to indicate new official, stable release versions of Bitcoin Core.
The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.
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. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests, written
in Python, that are run automatically on the build server.
These tests can be run (if the test dependencies 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.
Translations
Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.
Translators should also subscribe to the mailing list.