582b2934e6
This contains the following two merges, as well as a few other changes:
Squashed 'src/secp256k1/' changes from 22f60a6..18f9f08
18f9f08 Pedersen commitments, borromean ring signatures, and ZK range proofs.
5161227 Add benchmark for ECDH multiplication
c40cb72 Expose API for constant time point multiplication
40adc7a Add constant-time `secp256k1_ecdh_point_multiply` for ECDH
ff9a397 Add zero/one tests to ecmult
729badf Merge pull request #210
2d5a186 Apply effective-affine trick to precomp
4f9791a Effective affine addition in EC multiplication
git-subtree-dir: src/secp256k1
git-subtree-split: 18f9f0821c5a7795b760763c99d545af96a22775
Squashed 'src/secp256k1/' changes from b0210a9..22f60a6
22f60a6 Merge pull request #245
61c1b1e Merge pull request #190
d227579 Add scalar blinding and a secp256k1_context_randomize() call.
c146b4a Add bench_internal to gitignore.
9c4fb23 Add a secp256k1_fe_cmov unit test.
426fa52 Merge pull request #243
d505a89 Merge pull request #244
2d2707a travis: test i686 builds with gmp
cf7f702 travis: update to new build infrastructure
bb0ea50 Replace set/add with cmov in secp256k1_gej_add_ge.
f3d3519 Merge pull request #241
5c2a4fa Fix memory leak in context unit test
14aacdc Merge pull request #239
93226a5 secp256k1.c: Add missing DEBUG_CHECKs for sufficiently capable contexts
6099220 Merge pull request #237
6066bb6 Fix typo: avg -> max
9688030 Merge pull request #236
d899b5b Expose ability to deep-copy a context
3608c7f Merge pull request #208
a9b6595 [API BREAK] Introduce explicit contexts
a0d3b89 Merge pull request #233
9e8d89b Merge pull request #234
65e70e7 Merge pull request #235
5098f62 Improve documentation formatting consistency
4450e24 Add a comment about the avoidance of secret data in array indexes.
6534ee1 initialize variable
d5b53aa Merge pull request #232
c01df1a Avoid some implicit type conversions to make C++ compilers happy.
bfe96ba Merge pull request #231
33270bf Add a couple comments pointing to particular sections of RFC6979.
41603aa Merge pull request #230
2632019 Brace all the if/for/while.
1897b8e Merge pull request #229
efc571c Add simple testcases for signing with rfc6979 extra entropy.
1573a10 Add ability to pass extra entropy to rfc6979
3087bc4 Merge pull request #228
d9b9f11 Merge pull request #218
0065a8f Eliminate multiple-returns from secp256k1.c.
354ffa3 Make secp256k1_ec_pubkey_create reject oversized secrets.
27bc131 Silence some warnings from pedantic static analysis tools, improve compatibility with C++.
3b7ea63 Merge pull request #221
f789c5b Merge pull request #215
4bc273b Merge pull request #222
137a8ec Merge pull request #216
7c3771d Disable overlength-strings warnings.
8956111 use 128-bit hex seed
02efd06 Use RFC6979 for test PRNGs
ae55e85 Use faster byteswapping and avoid alignment-increasing casts.
443cd4b Get rid of hex format and some binary conversions
0bada0e Merge #214: Improve signing API documentation & specification
8030d7c Improve signing API documentation & specification
7b2fc1c Merge #213: Removed gotos, which are hard to trace and maintain.
11690d3 Removed gotos, which are hard to trace and maintain.
122a1ec Merge pull request #205
035406d Merge pull request #206
2d4cd53 Merge pull request #161
34b898d Additional comments for the testing PRNG and a seeding fix.
6efd6e7 Some comments explaining some of the constants in the code.
ffccfd2 x86_64 assembly optimization for scalar_4x64
67cbdf0 Merge pull request #207
039723d Benchmarks for all internal operations
6cc8425 Include a comment on secp256k1_ecdsa_sign explaining low-s.
f88343f Merge pull request #203
d61e899 Add group operation counts
2473f17 Merge pull request #202
b5bbce6 Some readme updates, e.g. removal of the GMP field.
f0d851e Merge pull request #201
a0ea884 Merge pull request #200
f735446 Convert the rest of the codebase to C89.
bf2e1ac Convert tests to C89. (also fixes a use of bare "inline" in field)
fc8285f Merge pull request #199
fff412e Merge pull request #197
4be8d6f Centralize the definition of uint128_t and use it uniformly.
d9543c9 Switch scalar code to C89.
fcc48c4 Remove the non-storage cmov
|
||
|---|---|---|
| .tx | ||
| build-aux/m4 | ||
| contrib | ||
| depends | ||
| doc | ||
| qa | ||
| share | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| autogen.sh | ||
| configure.ac | ||
| COPYING | ||
| INSTALL | ||
| Makefile.am | ||
| pkg.m4 | ||
| README.md | ||
| sidechain-README.md | ||
Bitcoin Core integration/staging tree
What is Bitcoin?
Bitcoin is an experimental new 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 useable, binary version of the Bitcoin Core software, see https://www.bitcoin.org/en/download.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see http://opensource.org/licenses/MIT.
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 Bitcoin development team members simply pulls it.
If it is a more complicated or potentially controversial change, then the patch submitter will be asked to start a discussion (if they haven't already) on the mailing list.
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.
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.
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
Every pull request is built for both Windows and Linux on a dedicated server, and unit and sanity tests are automatically run. The binaries produced may be used for manual QA testing — a link to them will appear in a comment on the pull request posted by BitcoinPullTester. See https://github.com/TheBlueMatt/test-scripts for the build/test scripts.
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. See https://github.com/bitcoin/QA/ for how to create a test plan.
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.
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 messages 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 -regtest mode.
DEBUG_LOCKORDER
Bitcoin 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 which locks are held, and adds warnings to the debug.log file if inconsistencies are detected.