db283a6b6f
ec0fc14a22miniscript: remove P2WSH-specific part of GetStackSize doc comment (Antoine Poinsot)128bc104efqa: bound testing for TapMiniscript (Antoine Poinsot)117927bd5fminiscript: have a custom Node destructor (Antoine Poinsot)b917c715acqa: Tapscript Miniscript signing functional tests (Antoine Poinsot)5dc341dfe6qa: list descriptors in Miniscript signing functional tests (Antoine Poinsot)4f473ea515script/sign: Miniscript support in Tapscript (Antoine Poinsot)febe2abc0eMOVEONLY: script/sign: move Satisfier declaration above Tapscript signing (Antoine Poinsot)bd4b11ee06qa: functional test Miniscript inside Taproot descriptors (Antoine Poinsot)8571b89a7fdescriptor: parse Miniscript expressions within Taproot descriptors (Antoine Poinsot)8ff9489422descriptor: Tapscript-specific Miniscript key serialization / parsing (Antoine Poinsot)5e76f3f0ddfuzz: miniscript: higher sensitivity for max stack size limit under Tapscript (Antoine Poinsot)6f529cbaafqa: test Miniscript max stack size tracking (Antoine Poinsot)770ba5b519miniscript: check maximum stack size during execution (Antoine Poinsot)574523dbe0fuzz: adapt Miniscript targets to Tapscript (Antoine Poinsot)84623722efqa: Tapscript-Miniscript unit tests (Antoine Poinsot)fcb6f13f44pubkey: introduce a GetEvenCorrespondingCPubKey helper (Antoine Poinsot)ce8845f5ddminiscript: account for keys as being 32 bytes under Taproot context (Antoine Poinsot)f4f978d38eminiscript: adapt resources checks depending on context (Antoine Poinsot)9cb4c68b89serialize: make GetSizeOfCompactSize constexpr (Antoine Poinsot)892436c7d5miniscript: sanity asserts context in ComputeType (Antoine Poinsot)e5aaa3d77aminiscript: make 'd:' have the 'u' property under Tapscript context (Antoine Poinsot)687a0b0fa5miniscript: introduce a multi_a fragment (Antoine Poinsot)9164c2eca1miniscript: restrict multi() usage to P2WSH context (Antoine Poinsot)91b4db8590miniscript: store the script context within the Node structure (Antoine Poinsot)c3738d0344miniscript: introduce a MsContext() helper to contexts (Antoine Poinsot)bba9340a94miniscript: don't anticipate signature presence in CalcStackSize() (Antoine Poinsot)a3793f2d1aminiscript: add a missing dup key check bypass in Parse() (Antoine Poinsot) Pull request description: Miniscript was targeting P2WSH, and as such can currently only be used in `wsh()` descriptors. This pull request introduces support for Tapscript in Miniscript and makes Miniscript available inside `tr()` descriptors. It adds support for both watching *and* signing TapMiniscript descriptors. The main changes to Miniscript for Tapscript are the following: - A new `multi_a` fragment is introduced with the same semantics as `multi`. Like in other descriptors `multi` and `multi_a` can exclusively be used in respectively P2WSH and Tapscript. - The `d:` fragment has the `u` property under Tapscript, since the `MINIMALIF` rule is now consensus. See also https://github.com/bitcoin/bitcoin/pull/24906. - Keys are now serialized as 32 bytes. (Note this affects the key hashes.) - The resource consumption checks and calculation changed. Some limits were lifted in Tapscript, and signatures are now 64 bytes long. The largest amount of complexity probably lies in the last item. Scripts under Taproot can now run into the maximum stack size while executing a fragment. For instance if you've got a stack size of `999` due to the initial witness plus some execution that happened before and try to execute a `hash256` it would `DUP` (increasing the stack size `1000`), `HASH160` and then push the hash on the stack making the script fail. To make sure this does not happen on any of the spending paths of a sane Miniscript, we introduce a tracking of the maximum stack size during execution of a fragment. See the commits messages for details. Those commits were separated from the resource consumption change, and the fuzz target was tweaked to sometimes pad the witness so the script runs on the brink of the stack size limit to make sure the stack size was not underestimated. Existing Miniscript unit, functional and fuzz tests are extended with Tapscript logic and test cases. Care was taken for seed stability in the fuzz targets where we cared more about them. The design of Miniscript for Tapscript is the result of discussions between various people over the past year(s). To the extent of my knowledge at least Pieter Wuille, Sanket Kanjalkar, Andrew Poelstra and Andrew Chow contributed thoughts and ideas. ACKs for top commit: sipa: ACKec0fc14a22achow101: ACKec0fc14a22Tree-SHA512: f3cf98a3ec8e565650ccf51b7ee7e4b4c2b3949a1168bee16ec03d2942b4d9f20dedc2820457f67a3216161022263573d08419c8346d807a693169ad3a436e07
Bitcoin Core integration/staging tree
For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.
What is Bitcoin Core?
Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and graphical user interface, which can be optionally built.
Further information about Bitcoin Core is available in the doc folder.
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 (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be
completely stable. Tags are created
regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.
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.
These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py
The CI (Continuous Integration) systems make 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.