Single-Sig and Multisig from First Principles

Multisig is an authorization policy, not a security level

Ask a Bitcoiner what multisig is for and the first answer will usually be some version of:

More security.

A small stack gets single-sig. A larger stack gets multisig. A very large stack gets multi-vendor multisig, with several hardware wallets, several seed phrases, several locations and enough recovery material to make the setup feel appropriately serious.

I understand how we got here. Some of these setups work. Some threat models genuinely benefit from multiple independent signers.

But I think the usual discussion starts one layer too late.

Much of modern Bitcoin custody is built around BIP39. Once the private key is represented primarily as 12 or 24 words, custody naturally becomes a problem of protecting those words. We stamp them into metal, hide them, distribute them, put them behind dedicated devices and eventually create several independent seeds so that losing or compromising one does not destroy the entire setup.

Multisig then gets pulled into that architecture as another form of redundancy.

I want to rewind the discussion to before all of that.

Start with Bitcoin Core.

A wallet contains private keys. The wallet can be encrypted. The encrypted wallet can be copied. Those copies can be stored in several places. Separately, Bitcoin has a spending condition that determines which signatures can move a coin.

That separation gives us a cleaner way to reason about custody.

Before asking whether we need single-sig or multisig, ask:

Who should have the authority to move the money?

Everything else follows from that.

Start by naming the problem

There is a simple engineering habit that is useful far beyond Bitcoin: do not add a mechanism until you know what problem it is solving.

Suppose you are worried that a storage device may die. You need another recoverable copy of the key material.

Suppose you are worried that somebody may steal one of those copies. Encryption can make possession of the file insufficient to recover the wallet, assuming the passphrase is strong and protected separately.

Suppose you are worried about malware on the machine that holds your keys. Then the environment that generates and uses those keys matters. A dedicated Linux machine used only for Bitcoin Core has a very different attack surface from the computer you use every day for email, browsing and downloaded software.

Now suppose your requirement is different: one independent signing authority must never be sufficient to spend the Bitcoin.

That is where multisig enters the picture.

These problems interact, but they are not interchangeable.

A backup answers a recovery problem.

Encryption addresses exposure of backup material.

A dedicated signer reduces the attack surface around key generation and signing.

Multisig changes the authorization condition.

If we collapse all of them into one vague category called security, it becomes very easy to use an expensive mechanism for a problem that had a simpler solution.

What single-sig actually says

Take the simplest example.

Alice owns 1 BTC. One private key can produce the signature required to spend it, and Alice is the only person with access to that key.

That is single-sig.

Now Alice gives Bob access to the same wallet because she wants him to recover the Bitcoin if something happens to her.

The spending policy has not changed.

Alice can spend.

Bob can spend.

Either person can independently produce the one signature Bitcoin requires.

This is still single-sig.

That matters because people sometimes use single-sig as shorthand for “one person has access.”

That is not what the spending condition says.

It says that one valid signing authority is sufficient.

Alice and Bob might have an agreement that Bob will never touch the wallet while Alice is alive. That agreement can be perfectly sensible, especially inside a close family.

But the restriction exists between Alice and Bob. Bitcoin does not enforce it.

Bitcoin does not know that Bob is an heir. It does not know whether Alice is alive. It does not know whether Alice verbally approved the transaction.

It can only evaluate whether the spending condition has been satisfied.

That gives us our first useful separation: the social agreement and the cryptographic spending condition live at different layers.

Backup is a different axis

Now put that single-sig wallet in Bitcoin Core.

Encrypt the wallet with a strong passphrase.

Make several copies of the encrypted wallet file.

Keep those copies on different media and in different locations. Protect the passphrase separately. Write recovery instructions. Test the recovery procedure.

You might end up with ten recoverable copies of the wallet.

You still have one signing authority.

Those ten files are not ten keys participating in a spending policy. They are ten ways of recovering the same key material.

A backup asks:

Can I recover this signer after a failure?

Multisig asks:

Which independent signers must approve this spend?

Once those questions are separated, both problems become easier to reason about.

Look at the marginal cost

There is another clue that backup and multisig belong to different layers.

Imagine that I already have three well-protected copies of an encrypted Bitcoin Core wallet and decide that I want a fourth.

Operationally, creating the fourth copy is trivial.

A fifth is also trivial.

So is a tenth.

The security cost is not literally zero. Every additional copy is another object that must remain encrypted, accounted for and included in the recovery plan.

But the marginal complexity is tiny.

I do not need another signing implementation.

I do not need another derivation path.

I do not need another independent wallet.

I do not need another person.

I do not need another device lifecycle that somebody will have to understand ten years from now.

Now compare that with adding an independent signer.

That signer needs a key.

The key needs backups.

Its recovery procedure must work.

The signer has to be included in the wallet policy.

The other participants need the information required to reconstruct that policy.

The signing workflow becomes more involved.

The additional work may be worth it because the extra signer changes the authorization policy in a way you genuinely need.

But if the only goal was:

I want another way to recover if something disappears.

then creating another independent signing authority is an extraordinarily expensive way to produce redundancy.

This is what I mean when I say:

Complexity is a security cost.

Simple systems are not automatically secure.

The point is that every moving part creates another assumption that has to remain true.

Build one good signer first

My preferred way to reason about custody starts with one complete signer.

For long-term cold storage, that could be a generic laptop with a clean Linux installation, dedicated to Bitcoin Core and kept offline.

The fact that the machine was manufactured as a general-purpose computer matters less to me than what it is allowed to do in this role.

If it never browses the web, never reads email, never installs random applications and never participates in everyday computing, its operational environment is much narrower than the phrase general-purpose computer suggests.

The Bitcoin Core wallet is encrypted.

There are redundant copies of the encrypted wallet.

The passphrase is protected separately.

Recovery instructions exist.

Most importantly, recovery is actually tested.

None of this makes the system invulnerable.

Commodity hardware can fail.

Linux can have bugs.

Bitcoin Core can have bugs.

Encryption depends on a strong secret.

Offline procedures can be executed badly.

What I like about this architecture is that each component has a legible job and the number of components remains small.

Generic hardware provides computation without adding a Bitcoin-specific device vendor and its own firmware, supply-chain and product lifecycle.

Linux provides the operating environment.

Bitcoin Core generates and uses the keys.

Encryption makes possession of the wallet file insufficient on its own.

Backups protect against loss of storage media.

A recovery drill checks whether the whole recovery path still works.

Once I understand that unit, I can reuse it.

That matters because multisig should be built from complete signers, not from half-understood key fragments whose only apparent purpose is to occupy another multisig slot.

Now change the requirement

Suppose Alice and Bob jointly control 1 BTC.

They do not merely want both people to have access. They specifically want neither person to be able to spend alone.

Single-sig cannot enforce that rule.

A 2-of-2 multisig can.

Alice has one independent signer.

Bob has another.

The Bitcoin can move only when both signatures are present.

The multisig has not solved Alice's backups. Alice still needs to be able to recover her signer.

It has not solved Bob's backups either.

What changed is the relationship between their two authorities.

Bitcoin now enforces unanimous consent.

And unanimous consent has consequences.

If Alice wants to spend and Bob refuses, nothing moves.

It does not matter whether Bob is being reasonable. It does not matter whether they previously agreed that he should sign.

The policy says two signatures.

One signature is not enough.

That means a 2-of-2 gives both participants veto power.

Sometimes that is exactly what you want.

A third signer changes the decision rule

Now imagine Alice and Bob want shared control, but they do not want one disagreement or disappearance to freeze the treasury forever.

They add Carol.

Carol might be a mutually trusted friend, an attorney, another shareholder or a professional arbitrator. Her role is agreed before there is a dispute.

The policy becomes 2-of-3.

Alice and Bob can spend.

Alice and Carol can spend.

Bob and Carol can spend.

Nobody can spend alone.

And no single participant has unilateral veto power.

If Bob refuses a transaction that Alice believes falls within their prior agreement, Alice can take the issue to Carol.

Carol is not functioning as “backup number three.”

She is exercising an independent authorization role.

The third signer changes the decision rule.

What about losing one signer?

This is where the terminology gets slippery because multisig can absolutely create useful fault tolerance.

In a 2-of-3 wallet, losing one signer does not necessarily freeze the funds. The remaining two can still satisfy the policy.

Likewise, compromise of one signer alone does not give an attacker enough signatures to spend.

Those are real security properties.

But they do not make backup and multisig the same thing.

Each signer still needs a recovery plan.

Suppose Alice loses her signer. Bob and Carol can still move the money.

Now suppose Carol's wallet was never backed up correctly and her machine dies before they do so.

What looked like a comfortably redundant 2-of-3 has become an unspendable 1-of-3.

Threshold policies can tolerate failures between signers.

Backups make each signer recoverable within itself.

You have to reason about both layers.

Complexity has to earn its place

This is where I part ways with the current fashion for multi-vendor hardware-wallet multisig.

If multi-vendor means several Bitcoin-specific signing products from several Bitcoin hardware companies, I do not consider that an attractive architecture for my own long-term custody.

Yes, vendor diversity can reduce some common-mode risks.

But it also deliberately brings several Bitcoin-specific firmware stacks, device lifecycles, update mechanisms, supply chains and vendor assumptions into the same system.

I would rather avoid that entire category of dependency where I can.

If I ever wanted hardware diversity because of a specific threat model, I would much rather diversify across generic commodity computers used as dedicated signers.

Perhaps one signer runs on one class of ordinary laptop and another on different generic hardware, with both running a carefully controlled Linux and Bitcoin Core environment.

Even then, I would only take on that additional complexity for a narrow threat model that actually justified it.

I would not do it because “more vendors” has become synonymous with “more security.”

That distinction matters.

A complicated setup can feel safe precisely because it is complicated.

Five devices.

Five vendors.

Several seed plates.

Multiple locations.

Different firmware.

Different recovery procedures.

A coordinator tying them together.

There is a lot to look at, so the setup feels serious.

But a long-lived security system has to survive maintenance, not merely setup day.

What still works in ten years?

What information do you need to reconstruct the wallet?

What happens when one tool disappears?

Can another person recover the system after you are gone?

When did you last test the entire path?

Every extra dependency should have a specific job.

If you cannot say what failure it addresses, it may not belong in the design.

There is also an opportunity cost.

You have a finite amount of attention.

Every hour spent tracking another signer, another device family or another recovery path is an hour you did not spend restoring the wallet from backup and proving that your recovery procedure actually works.

I would rather own a simple system I regularly recover than a sophisticated system I am afraid to touch.

The psychological cost is real too

There is another reason complicated setups are difficult to revisit.

People become attached to things they build.

If you bought several devices, learned each workflow, stamped several seed plates, drove backups to different locations and spent weeks thinking through every combination, questioning the architecture later is uncomfortable.

You did a lot of work.

You may also have built part of your sense of safety around that work.

So when somebody questions one of those components, it can sound less like engineering criticism and more like an attack on the security you believe you created.

That reaction is understandable, especially when the asset at risk cannot be recovered through customer support.

But sunk effort is not a security property.

The useful question remains:

What job is this component doing?

If we can answer that for every part of a custody setup, the architecture becomes much easier to evaluate.

Multisig starts to look different when you call it governance

Consider the common policies again.

A 1-of-1 says one independent authority can spend.

A 2-of-2 requires unanimous approval between two authorities.

A 2-of-3 creates a quorum in which no individual can spend or veto alone.

A 3-of-5 creates another decision rule.

The interesting variable is how authority is distributed.

This becomes much more obvious when Bitcoin belongs to an organization rather than one individual.

I can use a real example from my own entrepreneurial life before Bitcoin became the center of my work.

I co-founded a startup with six individual co-founders.

Alongside us, one of the co-founders was a corporate investor.

Another was the nonprofit organization from which the startup had originally spun out.

So there were eight parties in the ownership structure:

six individuals,

one corporation,

and one nonprofit organization.

Imagine that company had been operating on a Bitcoin standard and that we had contributed Bitcoin capital to its treasury.

The useful question would not have been:

How many dollars are we storing? Is this enough for multisig?

The real questions would have been about authority.

How many of the six individual founders should approve a treasury transaction?

Should the investor have approval rights?

Should the nonprofit have a vote?

Could one group veto everyone else?

What happens if one founder disappears?

How should a dispute be resolved?

Then it becomes more interesting, because the corporate investor was not really one person.

It was a company with its own owners, management and internal rules.

The nonprofit also had its own governance structure.

So one “signer” at the company level could itself represent an entire authorization process underneath it.

A corporation could have its own internal multisig or spending policy.

The nonprofit could have another.

An individual founder could maintain one complete independent signer.

Those lower-level decisions could then feed into the higher-level treasury policy.

Now multisig is being used for the thing it is unusually good at:

turning a distribution of authority into a spending condition Bitcoin can enforce.

This is where my criticism of BIP39 fits

BIP39 obviously works.

Millions of people have used mnemonic seeds successfully.

My criticism is architectural.

If the first lesson in custody is:

Your Bitcoin is these 12 or 24 words.

then custody becomes a problem of protecting those words.

Where do I store them?

What if the house burns down?

What if somebody finds the metal plate?

Should I split them?

Should I create another seed?

Should I use another device?

Should I put the seeds in different countries?

Should I put them into multisig?

The discussion starts at the recovery representation rather than at the spending policy.

I think that ordering has consequences.

It makes multisig easy to understand as “several seeds for more safety,” when a cleaner model treats the individual signer and the spending policy as separate layers.

Once those layers are clear, more advanced Bitcoin constructions become easier to reason about.

A timelocked recovery path is another condition describing when a different authorization becomes valid.

Miniscript becomes easier to understand because you are already thinking in spending conditions.

Taproot branches become easier to reason about because you already understand that different conditions can authorize the same coin.

Inheritance becomes a policy-design problem rather than merely a question of where to hide another copy of twelve words.

The same logic extends to companies, partnerships and federations.

This is what sound building blocks give you: the ability to add sophistication without losing track of what each component does.

Build complexity upward

There is a useful analogy with mathematics.

If somebody cannot understand an advanced result, staring at that result for another hour may not help.

The problem may sit several layers below it.

A definition was never clear.

An earlier operation became mechanical without being understood.

A concept was memorized rather than learned.

So you go backwards until you find the missing piece.

Fix it.

Then move forward again.

Custody works the same way.

If backup, encryption, signing and authorization are still tangled together in your head, adding a 3-of-5 multisig with recovery paths and timelocks will not untangle them.

It will bury the confusion under more machinery.

Get the primitive right first.

Build one signer that you understand.

Know exactly how its wallet is backed up.

Know how stolen backup media is protected.

Know how you restore it.

Actually restore it.

Then, if the spending policy requires two independent authorities, add another complete signer and require both.

If it requires arbitration, create a quorum.

If it requires delayed recovery, add that condition deliberately.

A system can become very sophisticated while the individual pieces remain understandable.

That is the kind of complexity I trust.

Single-sig is not beginner mode

Once you see these layers separately, the usual maturity ladder stops making much sense.

A single owner may rationally choose single-sig even for a very large amount if the threat model, backup architecture and inheritance plan support that choice.

A small business may rationally need multisig for a much smaller amount because no one employee or partner should have unilateral authority over company funds.

The difference is not sophistication.

The difference is the spending requirement.

A well-designed single-sig setup can include an offline signer, strong wallet encryption, redundant backups, a separately protected passphrase, tested recovery and clear inheritance instructions.

A badly designed multisig can still be fragile.

Counting keys tells you very little without understanding the systems behind them and the policy connecting them.

Start with authority

If I were designing a Bitcoin custody setup from scratch, I would not begin by choosing a hardware wallet.

I would not begin by deciding whether I want 12 words or 24.

And I would not begin by deciding whether the amount of Bitcoin is “big enough for multisig.”

I would write down who should be capable of authorizing a transaction.

If one person should have that authority, I would design one signer and make its recovery exceptionally good.

If two people must approve every transaction, I would use a policy that enforces that.

If two partners need an independent arbitrator, I would design a quorum around those three authorities.

If a board controls the funds, I would translate the board's actual decision rules into the spending policy as closely as Bitcoin allows.

Then I would solve backup, encryption, signer security and recovery for every key participating in that policy.

The order matters because it keeps different problems at the layer where they belong.

Recovery stays a recovery problem.

Signer security stays a signer problem.

Authorization stays a spending-policy problem.

And every new component has to explain why it exists.

When you can do that, multisig stops looking like an upgrade from single-sig.

It becomes a tool for expressing something much more precise:

who must agree before the money moves.

Practical context

Core wallet encryption protects private key material; it does not hide every transaction record, public key or label. Keep the passphrase separately recoverable, make a fresh backup after encryption or relevant wallet changes, and test restoration. An outer encrypted archive adds privacy and another recovery step. Bitcoin Core wallet documentation.

A complete policy and each participant’s signing contribution are separate recovery requirements. Check the actual descriptor, every permitted signer combination and any alternative recovery path. Bitcoin Core descriptors and PSBT workflow.