Litecoin multisig: how a 2-of-3 wallet works

Research checked 22 September 2026. Methods and reproducible files are documented below. The hero is an AI-generated editorial illustration.

A 2-of-3 Litecoin wallet requires signatures from any two of three designated keys. Losing one key need not prevent recovery. Someone obtaining one key alone should not be able to spend. Both statements depend on the actual spending policy and on keeping the keys independent.

We tested the rule with Litecoin Core 0.21.5.8 on a private regtest chain. The experiment constructed one ordinary transparent P2SH output, then tested all eight subsets of three keys against the same proposed spend. Four candidates passed and four failed. The downloadable script reproduces the experiment with new throwaway keys.

What 2-of-3 means at the transaction level

Call the keys A, B and C. A valid spend can be authorized by A+B, A+C or B+C. There is no distinguished “master key” in this basic policy. The third key does not receive an automatic veto. If two signers approve the same transaction, the absent third signer cannot stop the threshold from being met.

The coins are not divided into three balances. They are controlled by a spending condition attached to an output. In our legacy P2SH example, the funding address commits to a redeem script containing the three public keys and the two-signature requirement. Spending reveals that script and provides the required signatures.

This guide concerns transparent Litecoin outputs. It does not claim the same workflow is available for MWEB balances or that every Litecoin wallet supports multisig. Litecoin Core's version-pinned RPC implementation includes the createmultisig command used in the experiment. Support in one RPC is not proof of a polished hardware-wallet or mobile recovery workflow.

The eight combinations we actually tested

The test created a fresh data directory, disabled peer connections and listening, mined private regtest coins and funded the script with 1 test LTC. It prepared a spend of 0.9999 LTC, leaving a 0.0001 LTC fee. That fee was chosen to make the test simple; it is not a current fee estimate or recommendation.

For each subset of keys, the script called signrawtransactionwithkey and then testmempoolaccept. It did not broadcast any candidate. All eight candidates referred to the same unspent test output, so earlier successful candidates could not make later candidates fail as double spends.

Successful candidates were 337 virtual bytes in this run. Exact serialized size can vary with signatures and transaction structure. With the chosen 10,000-litoshi fee, the observed rate was about 29.67 litoshis per virtual byte. That describes this deliberately simple transaction; it does not price a typical multisig payment on today's network.

The zero-key and single-key candidates failed script validation. Providing all three private keys also succeeded, but the transaction only needed the threshold of two signatures. The result confirms the tested policy under this version of Core. It does not test hardware isolation, a coordinator application's safety, remote cosigner availability or a real disaster recovery.

Keep the lab separate from custody design

The demonstration generates all three keys in one temporary software wallet. That is convenient for enumerating combinations and unsuitable as evidence of independent custody. If malware could read that wallet, it could obtain all three keys. A 2-of-3 script would not repair the common point of compromise.

For real custody, decide which failures you want to survive before choosing devices or locations. Consider loss of a device, loss of a backup, theft of a backup, destruction of a building, an unavailable signer and a compromised coordinator. Two keys stored in the same password manager or photographed by the same phone are not independent against those failures.

A third key left at home next to the other two improves neither geographic separation nor resistance to a fire. Conversely, a remote key that nobody can locate or recover may add ceremony without practical redundancy. Document who can retrieve each key and what evidence they need, without creating a document that exposes two signing secrets together.

Back up the policy as well as the secrets

A seed phrase can restore a signer's key material in a compatible wallet. It does not necessarily recreate the full multisig arrangement by itself. Recovery may also need the other cosigners' public keys, threshold, key order, derivation paths, script type and network. The exact requirement depends on the wallet design.

For an HD multisig setup, retain a wallet-policy export or receive and change descriptors where the software supports them. Record public-key fingerprints and derivation paths alongside those exports. For the fixed-key P2SH experiment, the redeem script is the spending-policy record; the laboratory is not an HD seed recovery tutorial. Litecoin Core legacy wallet backups are also not interchangeable with every application's mnemonic format.

A public policy export cannot sign alone, but it may expose addresses and account history. Treat it as private financial information. Do not hide every copy alongside one indispensable device: losing that device should not also remove the instructions needed to use the remaining two keys.

Splitting one seed phrase into three pieces is a different scheme. It does not make the blockchain enforce two independent signatures. A secret-sharing backup can have a threshold for reconstruction, but after reconstruction it may still produce one ordinary signing key. Use the name of the actual mechanism when explaining your recovery plan.

A small recovery drill before funding the wallet

1. Export the proposed policy and save backups using the wallet's documented procedure. Check that receive and change paths are both covered.
2. Verify the first receiving address using independent signers or another trusted implementation that understands the same policy. A coordinator showing an address is not enough if that coordinator could substitute one.
3. Fund a small test amount you can afford to lose. Keep the remaining assets outside the new setup until the drill is complete.
4. Prepare a small outgoing payment. Have each participating signer inspect the destination, amount, fee and change policy on a trusted display or verification path.
5. Test A+B, A+C and B+C in separate rehearsals. For recovery, make one normal signing device unavailable and reconstruct its role from the documented backup procedure where applicable.
6. Record the software versions, policy checks, transaction IDs and recovery steps. Do not put seed phrases or private keys into the drill report.

Use fresh test outputs or reset the test environment between actual broadcasts. You cannot broadcast all three alternative spends of the same output and expect each to settle. Our automated experiment avoided that issue by validating without broadcasting.

After the drill, confirm that temporary computers, clipboard histories, print queues and cloud backups have not collected multiple signing secrets. If a test exposed production secrets to a less trusted environment, changing the arrangement may be necessary; closing the application does not erase the exposure.

Check compatibility before buying three devices

Ask a prospective wallet or coordinator six precise questions: does it support Litecoin on the intended network; which script type; which derivation path; how does each signer verify change; what policy export is available; and how can you recover without the original coordinator? Obtain version-specific documentation and run the small-value drill.

A device supporting single-signature LTC does not establish support for the multisig workflow you want. Likewise, a Bitcoin multisig tutorial is not sufficient proof of Litecoin compatibility. We have not certified a combination of commercial hardware wallets in this article. The tested implementation is Core's legacy P2SH RPC path.

Multisig is most useful when a recoverable two-party approval process fits the owner or organization. If maintaining several independent backups and verifying the policy is beyond the operator's routine, a well-tested simpler wallet may be easier to recover. Compare the procedures, not just the number of keys.

Run the regtest experiment

Download the Python experiment and recorded results. Save the script as multisig-regtest.py. Supply paths to your verified litecoind and litecoin-cli binaries:

python multisig-regtest.py /path/to/litecoind /path/to/litecoin-cli

On Windows use the .exe filenames and quote paths containing spaces. The script requires Python 3, creates a new temporary data directory, uses a loopback RPC port, disables external peer connections and stops the node when finished. It never points at your normal wallet directory. Its temporary wallet contains only generated regtest keys; do not reuse them or import real secrets into it.

Expected result: eight cases; only AB, AC, BC and ABC return both complete: true and mempool_allowed: true. New runs generate different public keys, scripts and transaction identifiers. Read the download-verification guide before running newly downloaded binaries.

Frequently asked questions

Can one lost key permanently lock a 2-of-3 wallet?

Not if the other two signing keys remain usable and the spending policy can be reconstructed. Missing wallet-policy information or incompatible recovery software can still prevent practical recovery.

Does multisig make transactions private?

Multisig is a spending-authorization mechanism. Our transparent P2SH test does not provide MWEB privacy, and its redeem script is revealed when spent.

Sources and limits

The eight-case test and published result file are original work run on 22 September 2026. The source implementation is pinned to Litecoin Core v0.21.5.8. For descriptor structure, see Core's descriptor documentation. For broader recovery planning, continue with our inheritance guide and cold-storage guide. No mainnet coins or commercial hardware devices were used in this experiment.