phantom/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-01-10 11:57:28 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
Bitcoin Core mirror and no, I don't give a fuck about Monero.
38961 commits 6 branches 321 tags 2.2 GiB
C++ 56.4%
C 22.8%
Python 17.5%
CMake 1%
Shell 0.8%
Other 1.2%
Find a file
Andrew Chow db283a6b6f
Merge bitcoin/bitcoin#27255: MiniTapscript: port Miniscript to Tapscript 
ec0fc14a22 miniscript: remove P2WSH-specific part of GetStackSize doc comment (Antoine Poinsot)
128bc104ef qa: bound testing for TapMiniscript (Antoine Poinsot)
117927bd5f miniscript: have a custom Node destructor (Antoine Poinsot)
b917c715ac qa: Tapscript Miniscript signing functional tests (Antoine Poinsot)
5dc341dfe6 qa: list descriptors in Miniscript signing functional tests (Antoine Poinsot)
4f473ea515 script/sign: Miniscript support in Tapscript (Antoine Poinsot)
febe2abc0e MOVEONLY: script/sign: move Satisfier declaration above Tapscript signing (Antoine Poinsot)
bd4b11ee06 qa: functional test Miniscript inside Taproot descriptors (Antoine Poinsot)
8571b89a7f descriptor: parse Miniscript expressions within Taproot descriptors (Antoine Poinsot)
8ff9489422 descriptor: Tapscript-specific Miniscript key serialization / parsing (Antoine Poinsot)
5e76f3f0dd fuzz: miniscript: higher sensitivity for max stack size limit under Tapscript (Antoine Poinsot)
6f529cbaaf qa: test Miniscript max stack size tracking (Antoine Poinsot)
770ba5b519 miniscript: check maximum stack size during execution (Antoine Poinsot)
574523dbe0 fuzz: adapt Miniscript targets to Tapscript (Antoine Poinsot)
84623722ef qa: Tapscript-Miniscript unit tests (Antoine Poinsot)
fcb6f13f44 pubkey: introduce a GetEvenCorrespondingCPubKey helper (Antoine Poinsot)
ce8845f5dd miniscript: account for keys as being 32 bytes under Taproot context (Antoine Poinsot)
f4f978d38e miniscript: adapt resources checks depending on context (Antoine Poinsot)
9cb4c68b89 serialize: make GetSizeOfCompactSize constexpr (Antoine Poinsot)
892436c7d5 miniscript: sanity asserts context in ComputeType (Antoine Poinsot)
e5aaa3d77a miniscript: make 'd:' have the 'u' property under Tapscript context (Antoine Poinsot)
687a0b0fa5 miniscript: introduce a multi_a fragment (Antoine Poinsot)
9164c2eca1 miniscript: restrict multi() usage to P2WSH context (Antoine Poinsot)
91b4db8590 miniscript: store the script context within the Node structure (Antoine Poinsot)
c3738d0344 miniscript: introduce a MsContext() helper to contexts (Antoine Poinsot)
bba9340a94 miniscript: don't anticipate signature presence in CalcStackSize() (Antoine Poinsot)
a3793f2d1a miniscript: 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:
    ACK ec0fc14a22
  achow101:
    ACK ec0fc14a22

Tree-SHA512: f3cf98a3ec8e565650ccf51b7ee7e4b4c2b3949a1168bee16ec03d2942b4d9f20dedc2820457f67a3216161022263573d08419c8346d807a693169ad3a436e07
2023-10-08 12:10:12 -04:00
.github Merge bitcoin/bitcoin#28561: build: Update qt package up to 5.15.10 2023-10-04 18:37:31 +01:00
.tx qt: Bump Transifex slug for 26.x 2023-09-01 07:49:31 +01:00
build-aux/m4 build: Bump minimum supported GCC to g++-9 2023-05-18 12:24:40 +02:00
build_msvc build: Update qt package up to 5.15.10 2023-10-04 14:00:57 +01:00
ci ci: Print Linux kernel info 2023-10-03 16:37:43 +02:00
contrib Merge bitcoin/bitcoin#25970: Add headerssync tuning parameters optimization script to repo 2023-10-05 11:28:29 +01:00
depends qt: enable -ltcg for windows HOST 2023-10-05 10:26:34 +01:00
doc doc: Drop references to assumevalid in assumeutxo docs 2023-10-06 19:43:32 +02:00
share depends: Bump MacOS minimum runtime requirement to 11.0 2023-06-22 15:28:47 +00:00
src miniscript: remove P2WSH-specific part of GetStackSize doc comment 2023-10-08 02:43:27 +02:00
test qa: bound testing for TapMiniscript 2023-10-08 02:43:26 +02:00
.cirrus.yml Merge bitcoin/bitcoin#28353: ci: Remove /ro_base bind mount, Remove LC_ALL=C from s390x task 2023-08-30 16:23:39 +01:00
.editorconfig ci: Drop AppVeyor CI integration 2021-09-07 06:12:53 +03:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore build: produce a .zip for macOS distribution 2023-09-15 13:47:50 +01:00
.python-version ci: Use DOCKER_BUILDKIT for lint image 2023-07-16 13:18:18 +02:00
.style.yapf Update .style.yapf 2023-06-01 23:35:10 +05:30
autogen.sh build: make sure we can overwrite config.{guess,sub} 2023-06-13 14:58:43 +02:00
configure.ac build: remove dmg dependencies 2023-09-15 13:47:50 +01:00
CONTRIBUTING.md doc: Explain squashing with merge commits 2022-05-24 08:17:41 +02:00
COPYING doc: Update license year range to 2023 2022-12-24 11:40:16 +01:00
INSTALL.md doc: Added hyperlink for doc/build 2021-09-09 19:53:12 +05:30
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00
Makefile.am build: produce a .zip for macOS distribution 2023-09-15 13:47:50 +01:00
README.md doc: Explain Bitcoin Core in README.md 2022-05-10 07:49:09 +02:00
SECURITY.md doc: Add my key to SECURITY.md 2022-08-23 16:57:46 -04:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

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.