1897b8eMerge pull request #229efc571cAdd simple testcases for signing with rfc6979 extra entropy.1573a10Add ability to pass extra entropy to rfc69793087bc4Merge pull request #228d9b9f11Merge pull request #2180065a8fEliminate multiple-returns from secp256k1.c.354ffa3Make secp256k1_ec_pubkey_create reject oversized secrets.27bc131Silence some warnings from pedantic static analysis tools, improve compatibility with C++.3b7ea63Merge pull request #221f789c5bMerge pull request #2154bc273bMerge pull request #222137a8ecMerge pull request #2167c3771dDisable overlength-strings warnings.8956111use 128-bit hex seed02efd06Use RFC6979 for test PRNGsae55e85Use faster byteswapping and avoid alignment-increasing casts.443cd4bGet rid of hex format and some binary conversions0bada0eMerge #214: Improve signing API documentation & specification8030d7cImprove signing API documentation & specification7b2fc1cMerge #213: Removed gotos, which are hard to trace and maintain.11690d3Removed gotos, which are hard to trace and maintain.122a1ecMerge pull request #205035406dMerge pull request #2062d4cd53Merge pull request #16134b898dAdditional comments for the testing PRNG and a seeding fix.6efd6e7Some comments explaining some of the constants in the code.ffccfd2x86_64 assembly optimization for scalar_4x6467cbdf0Merge pull request #207039723dBenchmarks for all internal operations6cc8425Include a comment on secp256k1_ecdsa_sign explaining low-s.f88343fMerge pull request #203d61e899Add group operation counts2473f17Merge pull request #202b5bbce6Some readme updates, e.g. removal of the GMP field.f0d851eMerge pull request #201a0ea884Merge pull request #200f735446Convert the rest of the codebase to C89.bf2e1acConvert tests to C89. (also fixes a use of bare "inline" in field)fc8285fMerge pull request #199fff412eMerge pull request #1974be8d6fCentralize the definition of uint128_t and use it uniformly.d9543c9Switch scalar code to C89.fcc48c4Remove the non-storage cmov 55422b6 Switch ecmult_gen to use storage types41f8455Use group element storage type in EC multiplicationse68d720Add group element storage typeff889f7Field storage type7137be8Merge pull request #1960768bd5Get rid of variable-length hex string conversionse84e761Merge pull request #195792bcdbCovert several more files to C89.45cdf44Merge pull request #19317db09eMerge pull request #194402878afix ifdef/ifndef25b35c7Convert field code to strict C89 (+ long long, +__int128)3627437C89 nits and dead code removal.a9f350dMerge pull request #1914732d26Convert the field/group/ecdsa constant initialization to static consts19f3e76Remove unused secp256k1_fe_inner_{start, stop} functionsf1ebfe3Convert 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.