Policy diagram · based on the article’s Litecoin Core regtest.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
Research checked 22 September 2026. Methods and reproducible files are documented below. The cover is a diagram of the example or system described in this guide.
A 2-of-3 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 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 commits to a redeem script containing the three and the two-signature requirement. Spending reveals that script and provides the required signatures.
Diagram of the tested transparent P2SH policy; it does not depict independent hardware custody. Download full-size SVG. Scroll the figure horizontally on a narrow screen.
This guide concerns transparent Litecoin outputs. It does not claim the same workflow is available for MWEB balances or that every Litecoin wallet supports . 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.
One funded output; eight independent signing candidates
Keys supplied
Signing complete
Mempool acceptance
none
No
Rejected
A
No
Rejected
B
No
Rejected
C
No
Rejected
AB
Yes
Accepted
AC
Yes
Accepted
BC
Yes
Accepted
ABC
Yes
Accepted
Successful candidates were 337 in this run. Exact serialized size can vary with signatures and transaction structure. With the chosen 10,000- 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 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 . 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.
Replace the arrangement before a second compromise
Two keys lost
No, unless a missing key has a usable backup
Recoverability of backups
Two keys compromised
Attacker may spend
Separation failed for the relevant threat
Coordinator unavailable
Potentially
Alternative software understands the policy
All keys backed up in one location
Depends on that location
A single event may defeat the threshold
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 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, , 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 are also not interchangeable with every application's mnemonic format.
Recovery inventory
Record
What it restores
Handling
Each signing secret / supported wallet backup
Ability to sign for that participant
Keep independent secrets separate
Threshold and cosigner public keys
Who can authorize a spend
Retain full policy export
Network, script type and key order
Correct spending condition
Do not infer from memory
Derivation paths and key fingerprints
HD key mapping where applicable
Preserve receive and change policy
Coordinator version and recovery instructions
Operational procedure
Test an alternative path
Successful small-value recovery record
Evidence the procedure worked then
Record no seed phrases or private keys
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 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
Export the proposed policy and save backups using the wallet's documented procedure. Check that receive and change paths are both covered.
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.
Fund a small test amount you can afford to lose. Keep the remaining assets outside the new setup until the drill is complete.
Prepare a small outgoing payment. Have each participating signer inspect the destination, amount, fee and change policy on a trusted display or verification path.
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.
Record the software versions, policy checks, 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 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:
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 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 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.
Litecoin (LTC)
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
In brief An output that locks coins to a script hash, so its address alone does not reveal the full spending rules.
A transparent output type that commits to a spending script through its hash. The spender supplies the redeem script and the data needed to satisfy it. P2SH can wrap different conditions, including multisignature arrangements and nested SegWit; the address format alone does not identify the exact spending conditions.
For example A P2SH output can contain P2SH-P2WPKH, but a wallet must identify that construction before you use the nested single-key fee model.
Common mistake Treating every P2SH output as nested SegWit or assuming that all P2SH inputs have the same size.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief Data derived from a private key that verifies signatures, rather than a secret key, address or proof of identity.
A cryptographic value derived from a private key and used to verify signatures. Addresses encode destinations or spending conditions and are not always a direct public-key hash. Public keys are not personal identities.
For example A node can use a public key to check a signature without learning the private key that created it.
Common mistake Confusing a public key with a private key, a receiving address or proof of the owner's real identity.
In brief A spending rule requiring a set number of key signatures, with the wallet policy also needed for recovery.
A spending policy requiring signatures from a stated number of keys, such as two of three. Recovery also needs the correct script or wallet policy and enough signing keys; one cosigner's seed is not necessarily sufficient.
For example In a 2-of-3 policy, any two of the three authorized keys can satisfy the signing threshold.
Common mistake Keeping enough seeds but losing the script or key-order information needed to reconstruct the wallet.
In brief A fee-sizing unit for ordinary transparent transactions, usually weight divided by four and rounded up.
A size unit used when quoting fees for ordinary transparent transactions. The usual calculation divides transaction weight by four and rounds up; node policy can also account for signature-operation cost. It can differ from the raw serialized byte count. Use the size unit expected by the quoted fee rate.
For example A transparent transaction with weight 565 has a virtual size of 142 vB, because the division rounds up.
Common mistake Multiplying a litoshi-per-vB rate by an unrelated raw-byte count or assuming the same formula covers every MWEB component.
In brief An informal name for 0.00000001 LTC, the smallest Litecoin unit, with 100,000,000 in one LTC.
An informal name for the smallest Litecoin unit: 0.00000001 LTC. One LTC contains 100,000,000 litoshis. Some software uses the inherited label satoshi, so always check which coin and unit a screen means.
For example 10,000 litoshis equal 0.0001 LTC; 1 litoshi equals 0.00000001 LTC.
Common mistake Confusing a fee quoted per virtual byte with that many litoshis for the whole transaction.
In brief Secret data a wallet uses to sign spending; one key may cover only part of a wallet and must never be shared.
Secret data used to authorize spending under the conditions attached to coins. In a simple single-key wallet, anyone with that key can spend the coins it controls. A wallet may manage many keys; never share them.
For example A wallet signs a spend using a private key; the recipient only needs your payment, not that secret key.
Common mistake Sharing a key with support or assuming one exported key necessarily backs up every address in a wallet.
Compare: Seed phrase vs private key
Seed Phrase
Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
Private Key
A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
In brief Who controls spending access; with a custodial service, the provider controls the keys behind your account.
Who controls the signing material and the process for moving funds. With a custodial service, the provider controls the relevant keys and you use an account. Self-custody places key and backup responsibility with you; an account password is not a private key.
For example An exchange withdrawal moves funds from the provider's control to an address whose signing keys your own wallet controls.
Common mistake Assuming an exchange balance and a self-custody wallet offer the same control, recovery process or withdrawal availability.
In brief Secret recovery words that need the right wallet format, settings and any extra passphrase; keep them offline.
A sequence of secret recovery words that some wallets use to rebuild keys. Recovery must match the original wallet's word format, settings and any extra passphrase; other wallets use different backup methods. Keep the words offline and follow the original wallet's official recovery instructions.
For example In a BIP39 wallet, the same words with a different extra passphrase produce a different seed and can show different addresses.
Common mistake Entering recovery words into a website, sharing them with support or assuming every Litecoin wallet uses the same word format.
Compare: Seed phrase vs private key
Seed Phrase
Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
Private Key
A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
In brief The key-generation route used by a hierarchical wallet to reproduce a particular account or address.
The sequence of steps used to derive a particular key from a hierarchical wallet's root material. Different accounts, address types or receiving and change branches can use different paths. Recovery needs the intended configuration, not just a valid-looking set of words.
For example Two apps can accept the same recovery words but show different addresses if they use different accounts or derivation paths.
Common mistake Treating an empty address view as proof that the words are wrong before checking the originating wallet's path and account settings.
In brief Recovery material for a specific wallet and format, whose coverage depends on when and how the backup was made.
A recovery copy of the material needed for a particular wallet, such as its wallet file and required configuration. Coverage depends on the format and when it was made; later imported keys may require a fresh backup.
For example A Core wallet-file backup made before a separate key import can omit that imported key.
Common mistake Treating a receiving-address list as a spending backup, or assuming every wallet file can be restored by another application.
In brief A linked record of transaction blocks that Litecoin nodes validate, choosing a valid chain by accumulated mining work.
A ledger of cryptographically linked blocks. Litecoin full nodes validate proposed blocks against consensus rules and select among valid chains by accumulated proof of work. Recent blocks can be reorganized, so confirmation depth matters.
For example A block explorer reads the chain so you can inspect where a transparent transaction was included.
Common mistake Assuming an explorer listing proves the sender's identity or that a recent block can never be replaced.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief A device designed to keep signing keys isolated while approving supported transactions, still requiring safe setup and backups.
A dedicated device designed to isolate signing keys and approve transactions through its supported interface. It still depends on correct setup, backups, supported software and careful review of the recipient and amount. Coins remain recorded on the blockchain.
For example A connected app prepares a payment while the hardware device displays details for you to verify before authorizing a signature.
Common mistake Assuming owning the device makes an exposed recovery phrase safe or removes the need to check what you authorize.
In brief A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
In brief Litecoin's optional layer that conceals amounts inside it, while base-chain and boundary activity can still reveal information.
Mimblewimble Extension Blocks, activated on Litecoin in May 2022. MWEB conceals amounts inside the extension layer; the base chain and boundary transfers can reveal information. Use maintained software and review the 2026 security postmortem.
For example An MWEB transfer uses compatible software and a different address format from an ordinary transparent Litecoin transfer.
Common mistake Assuming every LTC wallet or exchange accepts MWEB addresses, or that optional privacy removes all possible information leaks.
Downloadable data or code · Controlled wallet / regtest.
No separate completed review is recorded for this article. The byline identifies its author or responsible editor; it does not imply independent verification.
Research records
Controlled wallet / regtest · Pinned package linked in article
Controlled 2-of-3 regtest signing. It does not test every wallet interface or recovery arrangement.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
