Bitcoin Core

This commit simply stops supporting macOS 13, an operating system version that has reached end-of-life. It updates build and release documentation to require macOS 14 or newer. There is no security vulnerability being fixed here.

This commit changes how a Bitcoin Core CI script passes build options to the CMake build tool. Previously, all options were concatenated into a single string and run through 'bash -c', which could mishandle special characters in option values. Now the options are parsed into a proper array using 'eval' and passed directly to CMake. This is a code-quality and robustness improvement in internal CI tooling, not a fix for an active exploit in the Bitcoin software itself.

This commit is a merge of a Bitcoin Core pull request that adds and extends fuzz tests for the CConnman networking component. Fuzz tests are automated test harnesses that feed random or mutated inputs to functions to find bugs. The changes only affect test code and test utilities; they do not change the behavior of the live Bitcoin node software. There is no indication this commit fixes a security vulnerability or introduces one.

This commit fixes a mistake in a single Bitcoin Core test file. The test was accidentally asking for a transaction using the wrong identifier type (a regular transaction ID instead of a witness transaction ID). This only affects an internal functional test, not the actual Bitcoin network software that users run.

This commit only changes a single test file. It makes an existing functional test more reliable by using mock time instead of looping up to 100 times and hoping for the right timing. There is no change to the actual Bitcoin Core node software, so it cannot affect real users, wallets, or network behavior.

This commit only changes a test script used during Bitcoin Core's automated testing. It makes the test more reliable by increasing a timeout, using mock time to run faster, and fixing a minor method signature mismatch. There is no change to the actual Bitcoin network software that users run, so it has no security impact on real Bitcoin nodes or users.

This commit only adds a new automated test. The test checks that when a user presses Ctrl-C (or sends SIGTERM) while the node is handling a long-running 'waitforblockheight' RPC call, the node currently does not shut down immediately and instead waits for the RPC to time out. The commit itself does not fix the problem; it only creates test coverage so a later commit can prove the fix works.

This commit changes how Bitcoin Core wallets store temporary secret signing data (MuSig2 'secnonces') for multi-signature transactions. Previously, these secrets may have been kept in a more general signing provider; now they are kept inside the wallet's descriptor key manager. The change is defensive: it ensures these one-time secrets stay only in memory and are never written to disk, which prevents a dangerous nonce-reuse bug that could leak private keys. The commit itself is a small code move/addition, not a complete fix, and the commit message does not call it a security vulnerability.

This commit only adds a new automated test file for the MuSig2 multi-signature wallet feature. It does not change any production wallet, cryptography, or consensus code. There is no security-relevant change to the software users run.

This commit adds wallet-side support for producing MuSig2 aggregate and partial signatures when signing Taproot transactions. It is a feature implementation, not a fix for a known vulnerability. There is no evidence in the commit or supplied references that this change addresses a security bug, disclosure, or incident.

This commit adds a new helper class that wraps sensitive MuSig2 signing nonces in locked, non-swappable memory and prevents accidental copying. It is a defensive hardening change: it does not by itself fix an active bug, but it reduces the risk that a secret nonce could leak through memory dumps, swapping, or programmer error. The change is forward-looking and only affects code paths that use MuSig2 multi-signature signing.

This commit adds support for copying MuSig2 multi-signature data between two internal data structures used when handling Partially Signed Bitcoin Transactions (PSBTs). It is a feature-completion change: previously, MuSig2 participant lists, public nonces, and partial signatures were not transferred when converting between PSBT fields and the signing engine's SignatureData object, or when merging two PSBT inputs/outputs. The patch makes those transfers happen consistently. There is no direct evidence in the commit that this fixes an exploitable vulnerability; it appears to be a correctness/functional improvement for an upcoming MuSig2 signing workflow.

This commit adds infrastructure for storing and retrieving MuSig2 secret nonces (temporary cryptographic values used in multi-signature setup) inside Bitcoin Core's signing provider classes. It is a code organization change that introduces storage methods and a deletion method, but does not by itself change how transactions are signed or validated. There is no indication in the commit that it fixes a known security bug.

This commit adds a new function that lets a Bitcoin Core wallet create a partial MuSig2 signature as part of a multi-party signing process. It is a feature addition, not a fix. There is no direct evidence in the commit or supplied references that this change introduces a security vulnerability.

This commit adds a new helper function that combines multiple MuSig2 partial signatures into one final Schnorr signature for Bitcoin transactions. It is a feature addition, not a fix. The code includes verification of each partial signature before aggregation, which is good defensive practice. There is no evidence in the commit or supplied references that this change addresses a security vulnerability.

This commit adds a new helper function for creating MuSig2 cryptographic nonces in Bitcoin Core. MuSig2 is a multi-signature scheme that lets multiple parties jointly sign a transaction. The change is a feature addition: it introduces a nonce generator, a session ID helper, and wiring for signing code. There is no direct evidence in the commit or supplied references that this fixes a known security vulnerability. It is best treated as a normal code addition that may carry implementation risks rather than a disclosed security patch.

This Bitcoin Core change makes the wallet's signing code record key-origin metadata for both the internal key and the final output key of a Taproot address, not just the internal key. That metadata helps external signers (like hardware wallets) understand which key path was used to derive the address. On its own this is a small correctness/data-availability fix; it does not directly change how coins are spent or introduce an obvious exploit, but missing key-origin data could previously have caused signing failures or user confusion for Taproot key-path spends.

This commit is a straightforward internal code refactor in Bitcoin Core's MuSig2 cryptographic helper module. It adds a new variant of an existing function that lets callers both compute an aggregate public key and optionally check it against an expected value, while making two previously public helper functions private to the source file. There is no bug fix, no security patch, and no disclosed vulnerability.

This commit is a small, additive change to Bitcoin Core's public-key derivation code. It adds an optional way for callers to retrieve the 'tweak' value used when deriving child public keys under the BIP32 standard. The change is needed so that a newer multi-signature scheme called MuSig2 can sign with derived keys. There is no direct evidence in the commit that this fixes a security bug; it appears to be a feature or API improvement.

This change tweaks how Bitcoin nodes schedule transaction announcements to inbound peers. Previously, all inbound peers were told about new transactions on the same shared timer, which could let a spy with multiple connections figure out when a node first learned of a transaction and possibly trace it back to its source. The patch splits that timer by network group so that different peer networks get staggered announcement times, making that timing-based fingerprinting harder. It is a privacy-hardening fix, not a fix for a code crash or theft bug.

This commit simply changes the download location for a third-party QR-code library used in Bitcoin Core's build system. The old website no longer hosts the source file, so the build script now fetches the same library version from GitHub instead. The commit message explicitly states the difference between the two source trees is immaterial, and the change is accompanied by a matching SHA-256 hash update. There is no indication of a security vulnerability or malicious change.

This commit changes how Bitcoin Core's dependency build system names its 'already downloaded' marker files. Previously the marker file included the downloaded file's original name; now it uses the package version plus the file's cryptographic hash. This is a hardening improvement that makes the build less likely to be confused if a downloaded file is renamed or replaced, but the commit itself does not claim to fix any active security vulnerability.

This change updates a Bitcoin Core GitHub Actions helper so that every environment variable starting with 'ACTIONS_' is passed into Docker builds, rather than only two specific ones. The stated goal is to fix Docker build caching on forks and GitHub-hosted runners. It is a CI/infrastructure-only change and does not alter Bitcoin node code, consensus rules, wallet handling, or network behavior. There is no direct security vulnerability in the diff, but it slightly widens the set of GitHub Actions secrets/tokens that are forwarded into the Docker build environment.

This is a minor cleanup in Bitcoin Core's dependency build system. It removes an extra file-existence check that was already being handled elsewhere. There is no security issue visible in the change.

This commit fixes a build-system bug in Bitcoin Core's dependency downloader. Previously, the build system would create a 'download finished' timestamp file before the download actually completed. If the download was interrupted or failed, that timestamp file could still exist, making the build system think the dependency was already downloaded and skip retrying. The fix moves the timestamp creation to after the download and checksum steps succeed. This is primarily a reliability/build correctness issue; direct security impact is limited and indirect.