Winnow

Who must approve a payment?

Winnow supports two signing policies for two useful stories: share control with other people, or require an additional signing device. Both use the wallet’s existing Bitcoin peer connection.

These are product choices, not restrictions of the cryptography: a threshold can also protect one person’s devices, and MuSig2 can also be shared between people.

Share control: any two of three

For a family reserve or shared treasury, three independent keys can require any two approvals. One signer can be unavailable and the other two can still spend. Any two can also spend without the third person’s agreement.

Start with Wallet → Save with other people. Choose co-owners and the threshold, then share the savings card before funding so each wallet starts watching. The account shows its actual signing policy and its confirmed balance.

The threshold is configurable. 1-of-n permits one key to spend. A name or “shared savings” label does not change that rule. Distinct public keys also do not prove that different people hold their secrets.

Winnow uses Taproot script-path multisig with an unspendable internal key: there is no secret key that bypasses the threshold. The receiving output alone does not reveal the threshold. Spending reveals the executed script, its keys, and the threshold. Taproot rules.

App journey and test evidence

Add a factor: the phone and another signer

For personal savings, keep one key on the phone and another on an independent signing device. A 2-of-2 MuSig2 policy requires both keys for every payment. Two keys on the same compromised device do not provide the intended separation.

In Advanced mode → Wallet → Require another signing device, add the phone’s key and a compatible participant’s public account key. Review the policy before funding. MuSig2 exchanges public nonces and then partial signatures; the final payment has one Taproot key-path signature.

The signature alone does not reveal the number of signers. This does not hide balances, transaction history, or signing coordination from everyone. Every participant remains required: losing a key and all its backups can lock the funds permanently. Winnow’s MuSig2 policy has no alternate recovery branch.

Current compatibility: the app journey uses an independent software signer as a fixture. It does not establish compatibility with a desktop application or a particular hardware wallet. Bitcoin Core round-two compatibility remains an open issue. A hardware secret would stay on its device; the desktop would coordinate, not import that secret into Winnow.

App journey and its exact limits · Core interoperability · MuSig2 specification

What can metadata prove?

The app derives the required key count from the spending descriptor. Names, contact cards, notes, and imported transaction labels cannot lower that requirement or establish who controls a key.

A signed policy statement could authenticate who made the statement and bind it to a descriptor. It still could not prove that no key copies exist, where they are kept, or how an attacker will behave. Winnow does not issue a “wrench-proof” certificate or add that claim to the blockchain.

Separating keys across independently controlled devices or people can make compromising one key insufficient. Physical coercion remains possible. A genuinely mandatory delay or independent approval would need to constrain every valid spending path; descriptive metadata cannot enforce either. Such additional policies are not implemented here.

Professional co-signers and trusts: an investigation

Unchained’s published standard custody model gives the client two of three keys, so the provider’s participation is optional. Its published Partner model describes clients holding a single key alongside other key agents. Unchained’s custody models.

That distinction matters: a backup co-signer and a required independent approver serve different purposes. In a 2-of-3 where the client holds one key, the two other holders can also spend together without the client.

Trust arrangements also need legal authority and key access to agree. Unchained describes trust and inheritance services, but Winnow has no partnership or verified integration with Unchained. A trust label in this app does not create a trust or a signing obligation. Unchained inheritance services.

Compatibility, recovery, and partner acceptance criteria

Advanced: descriptors and signing

Threshold accounts use tr(NUMS, sortedmulti_a(k, …)); imported multi_a orderings are also supported. MuSig2 accounts use tr(musig(k1, k2, …)/…) with BIP328 derivation. Winnow does not combine the two into a hidden alternate spending path.

PSBTv2 carries the proposed transaction, Taproot information, and signatures. The app checks known inputs and derives its own output scripts to recognize change; it does not trust a proposer’s change label or derivation metadata. It displays recipients, amounts, fees, and the signing policy before authorization.

MuSig2 secret nonces stay in the active signing screen’s memory. Leaving the screen abandons the session; completing a signature consumes its nonce. Co-signers must restart an abandoned exchange with fresh nonces.

Each account is watched through the same compact-filter flow as the everyday wallet. Creation height matters: importing a public policy does not automatically recover funds sent before this phone started watching it. Keep the policy and the required wallet history for recovery. Recovery behavior.

Current signing support is Taproot. Support for a different provider’s P2SH/P2WSH policies or PSBT conventions cannot be inferred from the shared word “multisig.” The planned P2WSH Safe is a separate proposal, not proof of that compatibility.

How the suites and artifacts support these claims