Multisig

Endereços que exigem mais de uma assinatura para gastar

• Eric de Castro
• Atualizado em 08/06/2026

Esta página é um acréscimo de Eric de Castro à tradução — não faz parte do conteúdo original do Greg Walker.

Um endereço comum de Bitcoin é trancado por uma chave privada: quem tem essa chave gasta os fundos, com uma assinatura. Simples — e perigoso: se essa única chave for roubada ou perdida, acabou.

Um endereço multisig (multiassinatura) muda isso: ele exige mais de uma assinatura para ser gasto. É como um cofre com várias fechaduras, que só abre quando um número combinado de chaves vira ao mesmo tempo.

A ideia: "m-de-n"

Todo multisig é descrito por dois números, m-de-n:

• n = quantas chaves existem no total.
• m = quantas assinaturas são necessárias para gastar.

O exemplo mais comum é o 2-de-3: existem 3 chaves, e quaisquer 2 delas, juntas, conseguem gastar. Nenhuma chave sozinha resolve nada.

Por que usar multisig

• Sem ponto único de falha. Num 2-de-3, um atacante que roube uma chave ainda não consegue tocar nos seus bitcoins — faltam assinaturas. E se você perder uma chave, as outras duas ainda gastam.
• Distribuir o risco. Você pode guardar cada chave num lugar diferente (casa, escritório, casa de um parente), em dispositivos air-gapped distintos. Roubar tudo de uma vez fica muito mais difícil.
• Herança. Um 2-de-3 pode deixar uma chave com um familiar ou advogado: você sozinho gasta no dia a dia (suas 2 chaves), mas se algo te acontecer, o herdeiro + uma chave de backup recuperam os fundos.
• Fundos compartilhados. Uma empresa pode exigir 2-de-3 sócios para mover o caixa; um casal, 2-de-2 para gastos conjuntos.

Como funciona: o script

No nível do Bitcoin, um multisig "puro" é um script P2MS (Pay to MultiSig). A trava (o script de bloqueio) lista as chaves públicas e diz quantas assinaturas são necessárias:

OP_2 <chave_pública_1> <chave_pública_2> <chave_pública_3> OP_3 OP_CHECKMULTISIG

Leia assim: "preciso de 2 (OP_2) assinaturas válidas, dentre estas 3 (OP_3) chaves". O opcode OP_CHECKMULTISIG é quem faz a verificação.

Destravando: as assinaturas

Para gastar, o script de desbloqueio fornece m assinaturas (no nosso caso, 2). Um detalhe importante: as assinaturas precisam vir na mesma ordem em que as chaves correspondentes aparecem na trava — o OP_CHECKMULTISIG confere uma por uma, da esquerda para a direita.

OP_0 <assinatura_1> <assinatura_2>

Aquele OP_0 extra no começo não é um engano: o OP_CHECKMULTISIG tem um bug histórico (um "off-by-one") que faz ele consumir um item a mais da pilha. Esse OP_0 é só um valor de enchimento para alimentar o bug — e ficou para sempre no protocolo.

Veja o multisig sendo verificado passo a passo: clique em "Exemplo P2MS" e depois em Passo para acompanhar a pilha enquanto o OP_CHECKMULTISIG confere as assinaturas.

Onde o script fica guardado: P2SH, P2WSH e P2TR

Na prática, quase ninguém usa o P2MS "pelado". Em vez disso, o script multisig é embrulhado, e o que vira endereço é só um resumo (hash) dele. O script completo só é revelado na hora de gastar.

• P2SH (endereços que começam com 3). O jeito clássico: o endereço é o hash do script multisig. Quando você gasta, apresenta o script inteiro (provando que bate com o hash) + as assinaturas.
• P2WSH (endereços bc1q…). A versão SegWit do anterior: mesma ideia, mas o script e as assinaturas vão na testemunha (witness), o que reduz a taxa.
• P2TR (endereços bc1p…, Taproot). O mais moderno. Com MuSig2, as várias chaves podem ser somadas numa única chave: o multisig fica indistinguível de um endereço comum on-chain — mais privado e mais barato. (Também dá para usar o "caminho de script" para esquemas m-de-n mais flexíveis.)

Monte o seu próprio multisig: escolha o m-de-n, sorteie chaves de exemplo (ou cole as suas) e veja o script e os endereços P2SH e P2WSH gerados de verdade.

Como as assinaturas se juntam (na prática)

Num multisig de verdade, as chaves costumam estar em dispositivos diferentes (idealmente air-gapped). Então as assinaturas não nascem todas de uma vez — elas são coletadas em rodadas, usando uma PSBT (transação parcialmente assinada):

1. A carteira monta a transação como uma PSBT (ainda sem nenhuma assinatura).
2. O primeiro dispositivo recebe a PSBT, confere os detalhes e adiciona a sua assinatura.
3. A PSBT — agora com 1 assinatura — vai para o segundo dispositivo, que adiciona a dele.
4. Quando juntou as m assinaturas necessárias, a transação está completa e pode ser transmitida para a rede.

Descriptors: a planta da carteira

Para uma carteira multisig, guardar só as sementes não basta: é preciso saber também como as chaves se combinam (m, n, o tipo de embrulho e as chaves públicas estendidas de cada uma). Essa "planta" é o descriptor, algo como:

wsh(multi(2, xpub_A/…, xpub_B/…, xpub_C/…))

O erro clássico. Num multisig, você pode ter todas as sementes e ainda assim ter dificuldade de recuperar os fundos se perder o descriptor (ou os xpubs das outras chaves). Faça backup do descriptor junto com as sementes — e, idealmente, teste a recuperação antes de guardar quantias sérias.

Montagens comuns

• 2-de-3 — o queridinho da auto-custódia. Ex.: 2 chaves com você (em lugares diferentes) e 1 de backup com um serviço de recuperação ou um parente.
• 3-de-5 — para quantias maiores ou grupos; tolera perder até 2 chaves.
• 2-de-2 — gastos conjuntos (um casal, dois sócios). Atenção: perdeu uma, travou tudo — então tenha um plano de backup.

Cuidados

• Mais complexidade. Mais chaves, mais backups, mais passos para assinar. Vale a pena para valores altos; talvez seja demais para o troco do dia a dia.
• Backup do descriptor + todos os xpubs (não só as sementes), como já alertamos.
• Coordenação. Assinar exige reunir os dispositivos/pessoas. É uma fricção saudável — mas é fricção.

Multisig + air-gapped é considerado o padrão-ouro da auto-custódia: várias assinaturas, cada chave num dispositivo que nunca toca a internet. Junta o melhor das duas ideias — sem ponto único de falha e sem chave exposta à rede.