Bitcoin Core mirror and no, I don't give a fuck about Monero.
Find a file
Ava Chow 76a33be21d
Merge bitcoin/bitcoin#28307: rpc, wallet: fix incorrect segwit redeem script size limit
2451a217dd test: addmultisigaddress, coverage for script size limits (furszy)
53302a0981 bugfix: addmultisigaddress, add unsupported operation for redeem scripts over 520 bytes (furszy)
9be6065cc0 test: coverage for 16-20 segwit multisig scripts (furszy)
9d9a91c4ea rpc: bugfix, incorrect segwit redeem script size used in signrawtransactionwithkey (furszy)
0c9fedfc45 fix incorrect multisig redeem script size limit for segwit (furszy)
f7a173b578 test: rpc_createmultisig, decouple 'test_sortedmulti_descriptors_bip67' (furszy)
4f33dbd8f8 test: rpc_createmultisig, decouple 'test_mixing_uncompressed_and_compressed_keys' (furszy)
25a81705d3 test: rpc_createmultisig, remove unnecessary checkbalances() (furszy)
b5a3289433 test: refactor, multiple cleanups in rpc_createmultisig.py (furszy)
3635d43268 test: rpc_createmultisig, remove manual wallet initialization (furszy)

Pull request description:

  Fixing https://github.com/bitcoin/bitcoin/issues/28250#issuecomment-1674830104 and more.

  Currently, redeem scripts longer than 520 bytes, which are technically valid under segwit rules, have flaws in the following processes:
  1) The multisig creation process fails to deduce the output descriptor, resulting in the generation of an incorrect descriptor. Additionally, the accompanying user warning is also inaccurate.
  2) The `signrawtransactionwithkey` RPC command fail to sign them.
  3) The legacy wallet `addmultisigaddress` wrongly discards them.

  The issue arises because most of these flows are utilizing the legacy spkm keystore, which imposes
  the [p2sh max redeem script size rule](ded6873340/src/script/signingprovider.cpp (L160)) on all scripts. Which blocks segwit redeem scripts longer than
  the max element size in all the previously mentioned processes (`createmultisig`, `addmultisigaddress`, and
  `signrawtransactionwithkey`).

  This PR fixes the problem, enabling the creation of multisig output descriptors involving more than 15 keys and
  allowing the signing of these scripts, along with other post-segwit redeem scripts that surpass the 520-byte
  p2sh limit.

  Important note:
  Instead of adding support for these longer redeem scripts in the legacy wallet, an "unsupported operation"
  error has been added. The reasons behind this decision are:

  1) The introduction of this feature brings about a compatibility-breaking change that requires downgrade
      protection; older wallets would be unable to interact with these "new" legacy wallets.

  2) Considering the ongoing deprecation of the legacy spkm, this issue provides another compelling
      reason to transition towards descriptors.

  Testing notes:
  To easily verify each of the fixes, I decoupled the tests into standalone commits. So they can be
  cherry-picked on top of master. Where `rpc_createmultisig.py` (with and without the `--legacy-wallet`
  arg) will fail without the bugs fixes commits.

  Extra note:
  The initial commits improves the `rpc_createmultisig.py` test in many ways. I found this test very
  antiquated, screaming for an update and cleanup.

ACKs for top commit:
  pinheadmz:
    ACK 2451a217dd
  theStack:
    Code-review ACK 2451a217dd
  achow101:
    ACK 2451a217dd

Tree-SHA512: 71794533cbd46b3a1079fb4e9d190d3ea3b615de0cbfa443466e14f05e4616ca90e12ce2bf07113515ea8113e64a560ad572bb9ea9d4835b6fb67b6ae596167f
2024-06-04 21:39:49 -04:00
.github ci: Roll test-each-commit Ubuntu 2024-05-15 09:53:04 +02:00
.tx qt: Bump Transifex slug for 27.x 2024-02-07 09:24:32 +00:00
build-aux/m4 Merge bitcoin/bitcoin#30049: build, test, doc: Temporarily remove Android-related stuff 2024-05-30 09:25:42 +01:00
build_msvc Merge bitcoin/bitcoin#29494: build: Assume HAVE_CONFIG_H, Add IWYU pragma keep to bitcoin-config.h includes 2024-05-07 14:14:03 -04:00
ci Merge bitcoin/bitcoin#30034: ci: add markdown link check job 2024-05-30 12:36:09 +01:00
contrib Merge bitcoin/bitcoin#21778: build: LLD based macOS toolchain 2024-05-29 09:42:05 +01:00
depends depends: Update Boost download link 2024-06-03 09:49:34 +01:00
doc Merge bitcoin/bitcoin#30154: doc: update mention of generating bitcoin.conf 2024-06-04 19:00:59 -04:00
share contrib: rpcauth.py - Add new option (-j/--json) to output text in json format 2024-04-25 08:32:28 -05:00
src Merge bitcoin/bitcoin#28307: rpc, wallet: fix incorrect segwit redeem script size limit 2024-06-04 21:39:49 -04:00
test Merge bitcoin/bitcoin#28307: rpc, wallet: fix incorrect segwit redeem script size limit 2024-06-04 21:39:49 -04:00
.cirrus.yml ci: Skip git install if it is already installed 2024-02-16 16:06:45 +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 Merge bitcoin/bitcoin#29733: build, macos: Drop unused osx_volname target 2024-04-02 14:57:22 +01:00
.python-version Bump .python-version from 3.9.17 to 3.9.18 2023-10-24 18:51:24 +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 --enable-lcov-branch-coverage 2024-05-30 10:36:55 +01:00
CONTRIBUTING.md doc: Correct pull request prefix for scripts and tools 2024-05-22 09:59:58 +02:00
COPYING doc: upgrade Bitcoin Core license to 2024 2024-01-10 16:29:01 -06:00
INSTALL.md doc: Added hyperlink for doc/build 2021-09-09 19:53:12 +05:30
Makefile.am Merge bitcoin/bitcoin#29739: build: swap cctools otool for llvm-objdump 2024-05-11 18:34:42 +08:00
README.md doc: Explain Bitcoin Core in README.md 2022-05-10 07:49:09 +02:00
SECURITY.md Update security.md contact for achow101 2023-12-14 18:14:54 -05:00

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.