Pin or bump the rust-bitcoin constraint: `^0.32.9` currently accepts the 0.33 pre-release prep

[DanGould]

Disclosure: claude coauthored but sanity checked.

The question for maintainers

payjoin/Cargo.toml declares bitcoin = { version = "0.32.7", features = ["base64"] }
in the working tree and 0.32.9 on master. Cargo.lock is gitignored, so CI
resolves fresh on every run.

Published bitcoin versions, newest first:

Version	Published	MSRV
0.32.102	2026-07-15	1.74.0
0.32.101	2026-06-24	1.74.0
0.32.100	2026-05-27	1.74.0 (yanked)
0.32.11	2026-07-22	1.56.1
0.32.10	2026-05-26	1.56.1
0.32.9	2026-05-05	1.56.1

Two lines are being published under the same major. The 0.32.1xx series carries
MSRV 1.74.0, matching 0.33.0-beta's, while the 0.32.x stable line stays at
1.56.1. which reads as rust-bitcoin's 0.33 pre-release channel shipped under the
0.32 major version number.

Cargo resolves ^0.32.9 as >=0.32.9, <0.33.0, and 0.32.102 satisfies that.
Semver-wise 0.32.102 outranks 0.32.11, so a fresh resolve picks the pre-release
line, not the stable one.

So: what is CI actually building against, and is that intended? Someone should
check a recent CI job's resolved tree before this issue is written up. payjoin
1.0.0 is published, which makes it worth knowing which of the two lines the
released artifact's users will resolve.

Depending on the answer, this issue becomes one of

(a) Constrain to the stable line. If the pre-release resolution is unintended,
tighten the constraint so 0.32.1xx cannot be selected, and bump to 0.32.11 on the
stable line. Small, mechanical, good first issue.

(b) Adopt the pre-release line deliberately. If 0.32.10x is where rust-bitcoin
wants consumers, then this is a real migration with an MSRV question attached
(1.74 for the dep against 1.85 for the workspace, so no conflict, but the CI matrix
should say so explicitly). (I favor B, but we should survey integrators to figure out their plans)

(c) Track the 0.33 migration. Separate, larger, and worth its own issue rather
than being folded in here.

Also in scope once the above is settled

bitcoin-units is pinned at 0.1.3 while 0.1.101 and 0.5.0 are both published — the
same two-line pattern, and it is listed under ignored in the manifest's
dependency-check config, which may be masking it.

[caarloshenriq]

CI does not resolve fresh. Cargo.lock is gitignored, but contrib/test.sh sources contrib/lockfile.sh and copies the committed lockfiles into place:

use_lockfile Cargo-recent.lock
DEPS="recent minimal"
for dep in $DEPS; do
    cp "Cargo-$dep.lock" "$LOCKFILE"

rust.yml runs bash contrib/test.sh; lint.sh and coverage.sh both call use_lockfile Cargo-recent.lock. So CI is deterministic.

What it builds against. cargo tree --locked -i bitcoin --all-features:

Lockfile	bitcoin
Cargo-minimal.lock	0.32.9 (stable line)
Cargo-recent.lock	0.32.102 (1xx line)

Both lines are already exercised, one per leg of the loop. In the recent lock the whole family moves together: base58ck 0.1.101, bitcoin-io 0.1.101, bitcoin-units 0.1.101, bitcoin_hashes 0.14.101. bitcoin-consensus-encoding 1.2.0 is in the recent lock and absent from the minimal one; only 0.32.102 declares it.

Correction to the MSRV table. Per crates.io, 0.32.101 and 0.32.102 declare rust-version 1.60.0, not 1.74.0. Only 0.32.100 declared 1.74.0, and it is yanked. 0.33.0-beta is 1.74.0. So the MSRV argument for the 1xx line being the 0.33 pre-release channel does not hold, and the CI matrix concern under (b) goes away against a 1.85 workspace.

What the lockfiles cannot answer. Libraries do not ship lockfiles. Published payjoin 1.0.0 declares bitcoin ^0.32.9 and bitcoin-units ^0.1.3 on crates.io, so anyone adding payjoin = "1.0" today resolves 0.32.102 regardless of what CI pins. Downstream is already on the 1xx line either way.

Confirmed this combination is what's actually green in CI: run #6421 on master (commit b15388d, Aug 25 2026) passed with this exact test.sh loop (https://github.com/payjoin/rust-payjoin/actions/runs/32866119104).

That pushes me toward (b), keeping Cargo-minimal.lock as the stable-line coverage it accidentally already is. Happy to take the mechanical part.