1897b8e
Merge pull request #229efc571c
Add simple testcases for signing with rfc6979 extra entropy.1573a10
Add ability to pass extra entropy to rfc69793087bc4
Merge pull request #228d9b9f11
Merge pull request #2180065a8f
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 #221f789c5b
Merge pull request #2154bc273b
Merge pull request #222137a8ec
Merge pull request #2167c3771d
Disable overlength-strings warnings.8956111
use 128-bit hex seed02efd06
Use RFC6979 for test PRNGsae55e85
Use faster byteswapping and avoid alignment-increasing casts.443cd4b
Get rid of hex format and some binary conversions0bada0e
Merge #214: Improve signing API documentation & specification8030d7c
Improve signing API documentation & specification7b2fc1c
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 #205035406d
Merge pull request #2062d4cd53
Merge pull request #16134b898d
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_4x6467cbdf0
Merge pull request #207039723d
Benchmarks for all internal operations6cc8425
Include a comment on secp256k1_ecdsa_sign explaining low-s.f88343f
Merge pull request #203d61e899
Add group operation counts2473f17
Merge pull request #202b5bbce6
Some readme updates, e.g. removal of the GMP field.f0d851e
Merge pull request #201a0ea884
Merge pull request #200f735446
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 #199fff412e
Merge pull request #1974be8d6f
Centralize the definition of uint128_t and use it uniformly.d9543c9
Switch scalar code to C89.fcc48c4
Remove the non-storage cmov 55422b6 Switch ecmult_gen to use storage types41f8455
Use group element storage type in EC multiplicationse68d720
Add group element storage typeff889f7
Field storage type7137be8
Merge pull request #1960768bd5
Get rid of variable-length hex string conversionse84e761
Merge pull request #195792bcdb
Covert several more files to C89.45cdf44
Merge pull request #19317db09e
Merge pull request #194402878a
fix ifdef/ifndef25b35c7
Convert field code to strict C89 (+ long long, +__int128)3627437
C89 nits and dead code removal.a9f350d
Merge pull request #1914732d26
Convert the field/group/ecdsa constant initialization to static consts19f3e76
Remove unused secp256k1_fe_inner_{start, stop} functionsf1ebfe3
Convert the scalar constant initialization to static consts git-subtree-dir: src/secp256k1 git-subtree-split:1897b8e90b
3.7 KiB
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/developer-notes.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.