Ledger Bitcoin app

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 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 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 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 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 simply turns on Link Time Optimization (LTO), a standard compiler feature that can make the app smaller and faster. There is no indication of a security bug or fix in the change itself or the commit message.

This commit adds support for using MuSig multi-signature key groups inside taproot multi_a wallet policies on Ledger devices, while deliberately blocking them in sortedmulti_a. It also fixes a subtle parsing bug: previously, key expressions inside multi_a/sortedmulti_a were allocated one-by-one in a memory buffer, which would interleave badly with MuSig's own allocations and corrupt the in-memory layout. The new code parses all the keys into a temporary stack array first, then copies them into one contiguous allocation. Separately, the 'cleartext' human-readable display module now refuses to classify multisig patterns that contain musig keys, so the device falls back to showing the raw descriptor instead of potentially misleading text (for example, showing 'any 1 of two keys' for a musig that actually requires both).

This commit only adds a new automated test, plus screen snapshots used by that test. The test checks that after signing a Bitcoin transaction (PSBT), then signing a text message, the device does not accidentally reuse leftover display settings from the previous operation. The commit message says the test would have failed on an older version of the app, implying a prior UI bug existed. However, this commit itself does not change the app code, so it is not a fix and cannot be directly exploited. It is a regression test that documents a previous display-state issue.

This commit is a small follow-up cleanup to a previous pull request. It adds one safety step before validating a sorted key map, clarifies documentation about when missing map keys can be trusted, updates a copyright year, tightens a size check on a Bitcoin transaction field, and removes an oversized temporary buffer. The changes look like defensive hardening rather than a fix for an active bug, and the commit message gives no security context.

This commit is a code cleanup in Ledger's Bitcoin app. It replaces a memory-saving 'relative pointer' scheme with ordinary C pointers in the wallet-policy data structures. The change removes several hundred lines of pointer-conversion code and adds one compile-time check to make sure key-expression structures stay properly aligned when allocated back-to-back. There is no direct evidence in the commit that it fixes an active security bug; it reads as a maintainability/refactoring change to reduce complexity on newer Ledger devices that have more RAM.

This commit increases the memory buffers used to store parsed Bitcoin wallet policies inside Ledger's Bitcoin app. It is a preparatory change for an upcoming internal refactor that will make the policy data structure larger. The change itself does not fix a known bug or vulnerability, but it adjusts memory limits to avoid future out-of-memory failures. The Nano X keeps a smaller buffer than other devices, which the commit notes could cause some very complex policies to be rejected.

This commit fixes a bug in Ledger's Bitcoin app where malformed PSBT data could silently be treated as if it were missing. Specifically, if the 'nSequence' or 'fallback locktime' fields were present but unreadable (wrong length or bad proof), the app previously substituted default values and continued signing. Now it correctly rejects such malformed inputs. This prevents a malicious or buggy wallet client from getting the device to sign a transaction using sequence or locktime values the client never actually committed to.

This commit hardens a Ledger Bitcoin app security check. Previously, reading a value from a special data structure (a 'merkleized map') by key required the caller to first verify that all keys were sorted and unique; that was only a documented rule, not enforced. A malicious host could potentially trick the app into reading the wrong value for a key if the rule was skipped. The patch now tracks a 'keys are sorted' flag inside the map commitment itself and makes all by-key readers fail (via an internal assertion) if that flag is not set. It also adds a helper to validate maps that come directly from the APDU command (like the PSBT global map).

This commit only changes how the app's internal fuzz-testing harness behaves. It does not alter normal production behavior. The changes add compile-time guards so that certain safety relaxations (like skipping duplicate-public-key checks or forcing swap checks to run) are active only when the code is built in a special fuzzing mode. One small non-fuzzing change moves a Bech32 character table from a pointer into read-only data, which is a hardening improvement but not a fix for an exploitable vulnerability.

This commit fixes three places in the Ledger Bitcoin app's MuSig2 code where the result of an elliptic-curve point-addition operation was not checked for failure. If point_add fails (for example, because it produced the special 'point at infinity' or another error condition), the code previously continued using an invalid public key or nonce. The patch now aborts the signing operation and returns an error. It also corrects a debug-print index that was off by one and makes a type conversion explicit.

This update fixes a stack-exhaustion weakness in Ledger's Bitcoin app. A malicious or unusually crafted wallet policy (the text string that describes how coins can be spent) could make the app recurse so deeply that it runs out of call stack and crashes. The patch adds depth limits during parsing, reduces large on-stack buffers, and moves big buffers out of recursive functions so the app rejects oversized policies safely instead of crashing.

This commit adds automated tests to the Ledger Bitcoin app to check that very deep or heavily nested wallet policies are rejected safely. The tests confirm that an over-deep policy returns an error instead of freezing or crashing the device. The commit itself only adds tests; it does not change the app's actual handling code, so it is a defensive test addition rather than a fix.

This commit fixes a stack-overflow risk in Ledger's Bitcoin app when parsing wallet policies that deeply nest 'thresh' miniscript fragments. It limits nesting to four levels and prevents two helper functions from being inlined so their large local arrays don't multiply across every recursive call. Without the fix, a crafted policy could exhaust the device's limited stack and crash or potentially corrupt memory.

This commit refactors the Ledger Bitcoin app's wallet registration code so that the user-confirmation step runs in a separate function that the compiler is told not to inline. The stated goal is to reduce peak stack memory use by freeing large validation buffers before the UI rendering phase. The change itself is a defensive hardening/optimization patch; there is no direct evidence in the commit that it fixes an exploitable vulnerability.

This commit fixes a bug in the Ledger Bitcoin app's wallet-policy parser. Miniscript 'wrappers' (short letters like 'n' that modify a policy) were not counted toward the parser's recursion-depth safety limit. A crafted wallet descriptor with a long chain of wrappers could create an extremely deep policy tree, causing later recursive functions to exhaust the device's limited stack and crash. The patch now charges each wrapper against the same depth budget as nested expressions, and adds tests proving the boundary works.

This commit reduces a hard-coded limit in Ledger's Bitcoin app on how many branches a 'thresh' miniscript operator can have, from 128 down to 24. The change is framed as a memory-usage improvement, not a security fix. It also adds a test to make sure policies exceeding the new limit are rejected rather than analyzed with an undersized table. There is no direct evidence in the commit or supplied references that this was a disclosed vulnerability or that an exploit exists.