Bitcoin Core 32 Broke Multisig Co-Signing, and the Fix Is Buried in an RPC Flag

Your hardware wallet didn't change. Your co-signers didn't change. Then one person in your 3-of-5 quorum updates their node to Bitcoin Core 32 and the transaction stops signing.

That's the shape of the problem. Core 32 changed how its wallet builds PSBTs. PSBT means Partially Signed Bitcoin Transaction. It's the file format that lets several people sign the same transaction without passing private keys around. BIP-174 shipped version 0 back in 2017. BIP-370 shipped version 2 in 2021. Core 32 made v2 the default for its wallet.

Sounds like progress. Except the rest of the toolchain didn't move with it.

What Actually Broke

Two failure modes, and they hit differently.

The first is import. Core 32 wallets in a mixed-version setup are reporting failures bringing PSBT v2 files back in. You build a transaction, hand it around, get signatures, and the coordinator chokes on re-import. A signing round that should take four minutes takes an afternoon and a group chat full of screenshots.

The second is quieter and more annoying. Even with an explicit RPC option available, the wallet can still write out v0 files in some configurations. So now you've got a version dance at both ends of the pipe. Old signers want v0. New Core wants v2. And there's a flag to bridge the gap, but it's a flag, which means somebody has to read documentation and set it correctly before the transaction window closes.

Who's testing that combination? That's an honest question and I don't think there's a satisfying answer. The matrix is Core 30 against Core 32, Core 31 against a Coldcard, a Ledger running firmware from 2023 against a coordinator that updated last Tuesday. Nobody owns that matrix. It just sort of exists as a shared assumption that everyone is roughly on the same page.

They aren't.

Who Eats the Cost

Let's follow the incentives.

Core developers get a cleaner format. PSBT v2 does real work. It carries the full transaction construction data, so you can build, update, and finalize in more flexible sequences. It's better plumbing. For a developer the change is obviously correct and obviously overdue.

But the cost of the change lands somewhere else entirely. It lands on the treasury team at a small fund running a 2-of-3 for cold storage. It lands on the family office that set up multisig in 2022, tested it once, and hasn't touched the config since. It lands on the self-custody user who did everything right, air-gapped the whole flow, and now discovers that "did everything right" has an expiration date.

Custodians win here. Exchanges win. Anybody who can absorb a compatibility break because they've a team whose literal job is to absorb compatibility breaks. Every format fracture is a small subsidy to the people selling you a managed alternative. That's not a conspiracy, it's just arithmetic. Push enough friction onto self-custody and self-custody becomes a hobby for people with time.

And look, this isn't an argument against upgrading. Running 2021-era node software because you're scared of change is its own problem, and a worse one. Security patches matter. The point is narrower than that. In money software, a default that breaks existing quorums shouldn't ship as a default. Silent format changes are worse than loud bugs. A loud bug gets fixed on a Tuesday. A silent format change gets discovered mid-transaction by someone who's about to miss a settlement deadline.

Backward compatibility isn't a nice-to-have for a signing format. It's the whole product. PSBT v2 has been specified since 2021. Four years is a long time for a spec to sit there with partial signer support. That's a coordination failure across the wallet industry, and it's exactly the kind of failure that doesn't get fixed until it breaks something in public.

Here's the thing that bugs me most. The escape hatch exists. There's an RPC option that gets you v0 output. So this isn't a hard technical problem. It's a discoverability problem. The information is available and it isn't in front of you. And "read the release notes" is a rotten compatibility strategy for a system where the failure mode is a frozen wallet.

Permissionless means exactly what it sounds like. Nobody's coming to check your node version before you sign. That's the upside and the downside in the same sentence.

Check Your Versions, Then Check Your Flags

Concrete advice, no hedging.

If you run multisig with more than one node implementation or any hardware signer older than a year, assume you're on mixed versions right now. Inventory it today. Write down every node version, every firmware version, every coordinator build. Not next week. Today, while nobody's waiting on a signature.

Then run a test round. Build a dummy transaction, pass it through the full quorum, finalize it, and broadcast nothing. Do that before you need it. If it fails, you've found the problem on a Sunday afternoon instead of during a market move, which is the only time anyone actually wants out of a cold wallet.

And pin your versions deliberately. Upgrade as a group, not one person at a time. A multisig quorum that upgrades independently is a quorum that will eventually discover it can't co-sign, and it'll discover it at the worst possible moment.

The state isn't protecting you here. It isn't even involved. This is coordination, and coordination is your job.

The code doesn't ask for a license. It does ask you to read the release notes. Upgrade together, or don't upgrade at all.