Ledger Bitcoin app

This commit fixes how Ledger's Bitcoin client libraries convert older PSBTv0 transaction data into the newer PSBTv2 format that Ledger hardware wallets expect. The changes correct several field-handling bugs: the transaction locktime is now written to the right place, missing input sequence numbers are treated as the default final value, and the Rust client now forwards unknown PSBTv2 fields (such as required locktimes) instead of dropping them. It also rejects malformed PSBTs where v0 and v2 fields contradict each other, rather than producing an invalid PSBT that the device would refuse. These are client-side robustness fixes; they do not appear to be a security patch for the device firmware itself.

This commit fixes a small bug in the Python helper library that builds unsigned Bitcoin transactions from PSBT data. Previously, if a PSBT did not explicitly include a per-input sequence number, the code would crash with an assertion error. The change follows the BIP-370 standard and HWI by treating a missing sequence number as the default final value (0xffffffff). This is a client-side convenience fix; it does not change how the Ledger device itself validates or signs transactions.

This commit only updates a version number from 0.6.2 to 0.7.0 in two Rust package files. It is a routine bookkeeping change because the public interface of the PSBT module changed, requiring a minor version bump under semantic versioning rules. No code behavior changes are present in the diff.

This commit only changes hardcoded test data used in JavaScript unit tests. It removes an invalid zero-value locktime field from two PSBT (Partially Signed Bitcoin Transaction) test fixtures so they conform to the BIP-370 standard. No production code, device firmware, or user-facing behavior is changed.

This commit fixes three bugs in a Python helper that converts modern PSBTv2 transaction data into the older PSBTv0 format used by Ledger hardware wallets. The bugs could silently corrupt the transaction's lock time and version fields during conversion, which might alter when a transaction becomes valid or what transaction format the device signs. The fixes ensure the correct values are copied before they are erased. There is no direct evidence this was exploitable as a security attack, but it could cause unexpected or invalid signatures in wallet software relying on this library.

This commit refactors how the Ledger Bitcoin app's Rust client converts a PSBT (Partially Signed Bitcoin Transaction) from version 0 to version 2. Previously, the code manually listed every PSBT field it knew how to serialize, which risked silently dropping newer or unknown fields. The new code lets the rust-bitcoin library do most of the serialization, then only adds, removes, or changes the specific fields that differ between v0 and v2. It also adds checks that reject malformed PSBTs where v2 fields already exist and conflict with the v0 transaction data. The change is a defensive cleanup that reduces the chance of an incomplete or inconsistent PSBT being sent to the hardware wallet.

This commit is a routine version bump from 2.5.0 to 2.5.1 for the Ledger Bitcoin app. It only updates the changelog and Makefile version number. No code changes are present in the diff, and no security fixes or vulnerabilities are described.

This commit is a large internal refactoring of the Ledger Bitcoin app's wallet-policy parser. It replaces compact 'relative pointers' with ordinary memory pointers in the abstract syntax tree (AST) used to represent Bitcoin wallet descriptors. The change increases the memory each policy node uses, so the app also enlarges the policy buffer and updates related size limits. There is no direct evidence in the commit that this fixes an exploitable vulnerability; it appears to be a code-simplification and maintainability change. However, because it touches memory layout and parsing limits, it could indirectly affect security if the old relative-pointer scheme had subtle bugs or if the new buffer sizing introduces edge cases.

This commit fixes a size limit in the Ledger Bitcoin app that was too small. The app uses this limit when registering Bitcoin wallet policies (descriptions of how to spend coins). The old limit underestimated how long a key description can be when many derivation steps are used. If a real wallet policy exceeded the old limit, the app could reject valid wallets or, in the worst case, mishandle memory. The commit also removes an unused header and updates related comments.

This commit removes an old memory workaround in Ledger's Bitcoin app. Previously, a large data structure used during transaction signing was stored in global memory instead of on the function's stack, because some Ledger devices were thought to have only 8 KB of stack space. The update increases the allowed stack size for the Nano X and moves that data structure back onto the stack. This is a routine code cleanup, but it changes how memory is allocated during the most memory-intensive signing operation. If the new stack limit is slightly wrong, it could in theory cause stack overflows or memory corruption during signing on a Nano X.

This commit simply renames an internal Python package from `embit` to `_embit` (a common convention indicating it is private/implementation detail) and updates all import statements accordingly. There is no functional code change and no security fix or vulnerability present in the diff.

This update fixes a boundary bug in how the Ledger Bitcoin app parses wallet policies that use multi-path key expressions like /<M;N>/*. The app was supposed to reject hardened (high-security) derivation indexes, but it incorrectly allowed the exact boundary value 0x80000000 (2,147,483,648) as if it were unhardened. The patch changes the check from 'greater than' to 'greater than or equal to' so that hardened indexes are always rejected. The rest of the changes are minor cleanups: adding 'U' suffixes to numeric constants and using unsigned types in a few places to avoid comparison bugs.

This commit only adds 'U' suffixes to numeric constants in a header file and makes a few matching type adjustments in C source files so the code still compiles cleanly with strict compiler warnings. It is a code-quality cleanup, not a security fix.

This commit changes a JavaScript package dependency from allowing any compatible 3.x version of @bitcoinerlab/descriptors to a fixed, exact version (3.1.7). Pinning a dependency is often done to prevent unexpected future changes, but the commit itself does not say whether it fixes a security bug. It is a routine dependency-management change with no direct evidence of a vulnerability being patched.

This commit fixes a boundary-check bug in how the Ledger Bitcoin app parses wallet policies (BIP-388). The app was supposed to reject any hardened derivation step in a specific range expression, but it allowed the value 2147483648 (0x80000000) because the check used 'greater than' instead of 'greater than or equal to'. That value actually represents a hardened step, which is forbidden here. The fix changes the comparison so 0x80000000 is correctly rejected. If accepted, it could later cause address derivation or signing to fail or behave unexpectedly.

This commit only adds a new regression test to the Bitcoin app's test suite. The test checks that wallet policy key expressions reject a specific boundary value (2147483648, the first 'hardened' child index) where only 'unhardened' values are allowed. The commit message says an older version of the code incorrectly accepted this boundary value, but the actual code fix is not present in this commit—only the test is added. So this is a test-only change that documents a previously fixed parsing bug.

This commit simply renames a vendored (internally bundled) copy of the 'embit' library inside the Python client from `embit` to `_embit`. The leading underscore is a Python convention meaning 'private/internal use only.' No code behavior changes; only import paths are updated. There is no security fix or vulnerability here.

This commit adds a memory wipe of a cryptographic hash context after it is used to derive a secret random value in the Ledger Bitcoin app's MuSig multi-signature code. The change is described by the developer as a 'defense-in-depth' measure: once partial signatures are public, the internal randomness used to create them becomes sensitive, and leftover data in memory could theoretically help an attacker if they later gained access to the device's memory. There is no evidence this issue was exploited or publicly disclosed as a security vulnerability.

This commit fixes a bug in Ledger's Bitcoin app that could let a wallet policy slip through registration even when it contained unused or out-of-range public keys. The old code simply looked at the highest key index referenced in the wallet descriptor and assumed every key up to that number was used. That meant an attacker could craft a policy where the user's own key was listed as an unused extra key while the descriptor only required the attacker's key. The fix now explicitly counts which keys are actually referenced and rejects policies with gaps or unreferenced keys.

This commit adds an early safety check in the Ledger Bitcoin app. Before registering a new wallet policy, the app now verifies that each public key is a valid point on the Bitcoin elliptic curve. Previously, an invalid public key would only be caught later when trying to derive addresses. Catching it earlier prevents the device from storing a broken or potentially manipulated wallet policy.

This commit tightens checks in a Ledger Bitcoin app function that converts compressed public keys into full (x,y) public key points. Previously, the code did not verify that the supplied x-coordinate is a valid field element (less than the curve prime p) and did not confirm that the computed y really satisfies the secp256k1 curve equation. The patch adds both checks, rejecting malformed keys. Without these checks, a specially crafted compressed key could cause the function to produce a point that is not actually on the Bitcoin curve, which could then be used in subsequent cryptographic operations in unexpected ways.

This commit only adds new automated tests for an existing cryptography helper function. It does not change the actual app code that runs on Ledger devices, so it cannot by itself introduce or fix a security bug. The commit message notes that some of the new tests check failure cases that will be addressed in a later commit.

This commit fixes a spot in the Ledger Bitcoin app where a function that converts a compressed public key to an uncompressed one was called without checking whether it succeeded. Before the fix, if the conversion failed, the code would keep going with potentially invalid data. After the fix, the function's return value is checked and the operation aborts with an error if something went wrong. The change is small and defensive, but it removes a silent-failure path in cryptographic key derivation.

This commit is a routine code cleanup. It removes an unused SDK include path from the build configuration and deletes several unused header imports in a source file. There is no functional change and no security issue is indicated.

This commit is a straightforward internal code cleanup: it moves a temporary data cache used during Bitcoin transaction signing from a permanent global variable into a local stack variable inside the signing function. The change frees about 2.5 KB of always-reserved RAM and is described by the developer as removing an old workaround for a device stack-size limit that no longer exists. There is no indication in the commit that this fixes a security bug or changes behavior visible to users or attackers.