Shared wallets
Choose who must approve, back up every key, then fund the account.
Choose who signs
| Policy | Who can spend | What to plan for |
|---|---|---|
| Everyday · one key | Your phone signs. | A stolen key can spend. Losing the key and its backups loses access. |
| Both keys · 2-of-2 | Your phone and a second signer must both approve. | Neither can spend alone. Losing either key and all its backups locks the funds. |
| Any two · 2-of-3 | Any two of the three keys can sign. | One signer can be unavailable. The other two can also spend without that person's agreement. |
Independent keys need independent protection. Different public keys do not prove different owners, devices, or backups. These are examples: MuSig2 can be shared between people, and a threshold can protect one person's devices.
Set up the account
Any two of three
In Wallet → Save with other people, choose the co-owners and threshold. Share the savings card so every wallet starts watching before funds arrive. Check the actual policy shown in the account: 1-of-n allows one key to spend, regardless of the account's name.
Both keys required
In Advanced mode → Wallet → Require another signing device, add the phone's key and a compatible participant's public account key. Review the policy together. Winnow's MuSig2 policy has no alternate recovery branch: both keys remain necessary for every payment.
Bitcoin Core 31.1 is the demonstrated cosigner. The recorded journey receives and sends with phone-plus-Core MuSig2, then script-path 2-of-3 with Core co-owners. Hardware-wallet compatibility requires a separate verified integration. Set up with Bitcoin Core →
Back up before funding
- Open the account and choose Back up this wallet. Keep the file: it includes account setup, address positions, and tracked funds.
- Keep the phone's recovery words separately. Every other signer needs its own key backup.
- Make a fresh wallet backup after setting up an account and keep it current. Older files may omit shared accounts.
The default wallet export excludes recovery words. An export made with Include recovery phrase contains the phone's signing secret; protect it accordingly.
On a replacement phone, a file without recovery words restores watch-only access. The current import screen requires a file containing the words to restore this phone’s signing key; it has no separate word-entry field.
Recovery uses the file's saved history and scans forward for later payments. Recovery words or a public policy alone do not restore past payments. Signing exchanges are not restored; start a new exchange after recovery. Recovery requirements and limits →
Receive into the right account
Use the receiving address for the account whose policy you reviewed. Confirm the other wallets are watching, then fund it. The account shows its signing requirement and confirmed balance.
Importing an account later does not automatically find payments from before that wallet started watching. Keep its policy and wallet-history backup.
Review and approve
Select the account when sending, then check the recipients, amounts, fee, and policy before authorizing.
- 2-of-3: open the account and choose Approve a request. It accepts a Winnow request or a raw PSBT. In Advanced mode, expand Raw PSBT to copy or share a reply.
- MuSig2: use Continue signing to exchange public nonces and partial signatures with the other signer. After an interruption, choose Start again and begin a fresh exchange on both sides.
Private signing keys stay with their holders during signing. The exchange carries payment details, public nonces, and signatures. When the required signatures are complete, the payment can be broadcast over the wallet's existing Bitcoin peer connection.
What labels and policies can prove
The spending descriptor determines the required keys. Names, contact cards, notes, and imported labels cannot lower that requirement or prove who controls a key.
A signed policy statement could authenticate its author and descriptor, but not the location of keys, absence of copies, or protection from coercion. Metadata cannot enforce a delay or independent approval; such a rule would need to constrain every valid spending path. Winnow does not implement those additional policies or certify protection against coercion.
A signing key does not establish inheritance rights, a trust, or a provider's obligations. Winnow has no verified professional-cosigner or lending integration. Provider and recovery research →
Technical details: descriptors, privacy, and signing
Threshold accounts use tr(NUMS, sortedmulti_a(k, …)); imported multi_a orderings are supported. The unspendable internal key provides no secret-key bypass of the threshold. Receiving does not reveal the threshold; a script-path spend reveals the executed script, keys, and threshold.
MuSig2 accounts use tr(musig(k1, k2, …)/…) with BIP328 derivation and one Taproot key-path signature per input. The signature alone does not reveal how many keys signed. Transaction history and signing coordination can still reveal information. These policies do not combine into a hidden alternate spending path.
The app reads PSBTv0 and v2 and shares v0 files with Core. It checks known inputs and derives its own output scripts to recognize change; it does not trust the proposer's change labels or derivation metadata.
MuSig2 secret nonces stay in the active signing screen's memory. Leaving abandons the session; completing a signature consumes its nonce.
Accounts use the everyday wallet's compact-filter flow. Current signing support is Taproot; another provider's P2SH/P2WSH policies or PSBT conventions require separate verification. The proposed P2WSH Safe is not shipped support.