nonoise₿itcoin

I’m developing a Bitcoin application (“Bitcoin Monitor”) whose goal is not to replace wallets, but to orchestrate standard PSBT signing flows in a robust and long-term-resilient way.

My current setup is:

Bitcoin multisig 2-of-2 (A + B)

P2WSH

Two Ledger devices (Ledger A and Ledger B)

PSBT signing via HWI

Watch-only wallet / UTXO scanning handled by my application

I’ve validated this setup using Sparrow, but I want to remove Sparrow from the trust and dependency model.

The core concern I’m trying to address is:

If Sparrow disappears, I don’t want to be locked into a third-party UI to spend my funds.

Where I am today

My application can build a PSBT from known UTXOs.

I can call hwi signtx and obtain partial signatures.

Ledger requires a “first confirmation / review step” before signing, which I understand is normal behavior.

I want to reliably sign with Ledger A first, then Ledger B, and then finalize and broadcast the transaction.

What I’m trying to achieve (target architecture)

Use only Bitcoin standards (PSBT, descriptors, BIP32/48 derivation paths).

Make my application a PSBT orchestrator, not a wallet.

Let the Ledger devices perform all signing, with no private keys ever exposed.

Ensure the setup remains usable even if Sparrow, Specter, or any other UI disappears.

My questions

1. What is the minimum PSBT information required for Ledger to:

recognize inputs as belonging to the device

avoid alarming warnings

allow clean multi-step signing (Ledger A then Ledger B)

2. Is storing and using descriptors (receive + change) considered the recommended long-term approach for this use case?

3. In a 2-of-2 P2WSH multisig, is the following flow considered correct and robust?

build PSBT

sign with Ledger A (via HWI)

sign with Ledger B (via HWI)

finalize and broadcast (Bitcoin Core)

4. Are there any pitfalls to avoid when designing this without Sparrow (e.g. derivation paths, witness_utxo vs non_witness_utxo, Ledger-specific UX constraints)?

I’m explicitly trying to avoid proprietary formats and UI lock-in, and would appreciate feedback from people who have designed similar multisig, institutional, or long-term custody setups.

Thanks in advance

Victor