O que é um wallet descriptor e por que a seed não recupera um multisig

A crença de que a sua seed é tudo é quase verdade numa carteira de chave única. Numa carteira multisig, arranjo de várias chaves em que só um subconjunto delas precisa assinar para gastar, essa mesma crença vira uma armadilha silenciosa. Guardar as seeds em aço e perder o descriptor, o arquivo que descreve como as chaves se combinam, pode deixar você com duas chaves válidas e ainda assim incapaz de gastar.

Um wallet descriptor é um texto que descreve, de forma completa e sem ambiguidade, como uma carteira gera os seus endereços. Ele reúne o tipo de script, o quórum de assinaturas, as chaves públicas estendidas de todos os participantes e o caminho de derivação de cada uma. De posse desse texto, qualquer software compatível reconstrói exatamente a mesma carteira. Sem ele, num multisig, nem a posse de todas as seeds garante que você saiba quais endereços são seus.

A palavra chave aqui é público. O descriptor guarda as chaves públicas estendidas, conhecidas como xpub, a chave pública mestra a partir da qual todos os endereços de uma carteira são derivados. Ele não contém nenhuma chave privada. Isso muda tudo sobre como e onde guardar esse arquivo, e é o ponto que o marketing de autocustódia costuma ignorar.

Tenho as seed phrases das minhas hardware wallets do multisig guardadas, isso basta para recuperar meus bitcoins?

Não basta. Num multisig você também precisa do descriptor, ou no mínimo das chaves públicas estendidas de todas as chaves, do tipo de script e dos caminhos de derivação. As seeds provam que você pode assinar. O descriptor é o que diz ao software como remontar a carteira para saber o que assinar e onde estão os seus fundos. Uma coisa não substitui a outra.

O que o descriptor guarda

Pense no descriptor como a planta da carteira. A seed é a chave que abre a porta, mas a planta é o que diz onde a casa fica, quantas portas ela tem e qual combinação de chaves destranca cada uma. Num single-sig a planta é trivial e a carteira a reconstrói sozinha a partir da seed. Num multisig a planta tem partes que a sua seed não conhece, porque dependem das outras chaves.

• O tipo de script, que define o formato do endereço e como as assinaturas são verificadas.
• O quórum, por exemplo duas assinaturas de um conjunto de três chaves.
• A chave pública estendida (xpub) de cada participante, inclusive as que talvez você nunca use para assinar.
• O caminho de derivação de cada chave, a coordenada que aponta para o galho certo da árvore de endereços.
• A impressão digital de cada chave mestra, que permite ao software casar cada assinatura com a sua origem.

Por que a seed basta no single-sig

Numa carteira de chave única a seed carrega quase toda a informação necessária. A partir dela a carteira deriva todas as chaves privadas e todos os endereços de forma determinística, e o único dado externo que pode faltar é o caminho de derivação, tratado em o que é um caminho de derivação. Restaure a seed numa carteira compatível e, no pior caso, ajuste o caminho, e os fundos reaparecem. É por isso que o conselho de proteger a seed acima de tudo faz sentido no single-sig.

O multisig quebra essa simplicidade de propósito. Ele distribui o controle por várias chaves justamente para que nenhuma seja suficiente sozinha. O efeito colateral é que a informação para remontar a carteira também se distribui. Cada seed conhece apenas a sua própria parte. A visão do conjunto, o arranjo completo, mora no descriptor.

A armadilha silenciosa do multisig

Imagine um 2-de-3. Três hardware wallets, três seeds, guardadas em três cofres. A condição de gasto exige duas assinaturas de um total de três chaves. Mas há um detalhe que quase ninguém nota. O endereço em si é calculado a partir das três chaves públicas, não apenas das duas que vão assinar. Para o software montar o endereço e depois a transação, ele precisa conhecer as três chaves públicas ao mesmo tempo, inclusive a da chave que ficou de fora da assinatura.

Agora o cenário que revela o problema. Um incêndio destrói o cofre com a seed C. Você ainda tem A e B, duas chaves válidas, quórum de sobra para um 2-de-3. Só que você nunca salvou o descriptor. Sem a seed C, você não consegue recalcular a chave pública de C. E sem a chave pública de C, o software não remonta o arranjo 2-de-3, não sabe quais endereços são seus e não constrói uma transação válida. Você tem duas chaves boas, o saldo continua visível na blockchain para o mundo inteiro, e mesmo assim está trancado para fora.

“Duas chaves válidas de um 2-de-3 e ainda assim nenhum acesso. O esquema que existia para tolerar a perda de uma chave não tolera nada quando o descriptor foi para o lixo junto com a seed perdida.”

Com o descriptor guardado, a história é outra. Você importa o texto, o software reconstrói os endereços, inclusive os scripts que referenciam a chave pública de C, enxerga o saldo e deixa A e B assinarem. O descriptor é justamente o que torna o 2-de-3 recuperável depois da perda de uma chave. Ele carrega a chave pública da seed que você perdeu, que de outro modo seria impossível de recalcular.

O erro comum que esta peça corrige

O modelo mental errado é tratar a seed como backup completo também no multisig. Quem guarda três seeds em três cofres de aço acredita ter um backup triplo, mas na verdade tem três frações de um segredo e nenhuma cópia do mapa que as une. Se o arquivo de configuração vive apenas dentro de um software num computador que pode falhar, o backup tem um ponto único de falha escondido, exatamente o defeito que o multisig prometia eliminar.

A correção é simples de enunciar e fácil de esquecer. No multisig, o descriptor é backup de primeira classe, no mesmo nível de importância das seeds. Salve o arquivo de configuração exportado pela sua carteira em mais de um lugar, teste que ele realmente remonta a carteira e trate a atualização desse backup como parte do ritual sempre que o arranjo mudar. Um bom teste de recuperação vale mais do que qualquer certeza no papel.

O que isso significa para o investidor brasileiro

Quem sai de uma corretora para a autocustódia costuma pular direto para o multisig atraído pela promessa de segurança superior, muitas vezes antes de dominar a custódia de uma chave só. O risco no Brasil não é diferente do resto do mundo na mecânica, mas o custo de errar é agravado pela ausência de qualquer rede de resgate. Não há suporte, não há reversão, não há um cartório que devolva o acesso a bitcoins travados por um backup incompleto.

A implicação prática é dividir o backup em dois inventários distintos. O inventário das seeds, com sigilo máximo e distribuição geográfica. E o inventário do descriptor, protegido contra perda e contra bisbilhotice, mas passível de cópias em lugares onde jamais colocaríamos uma seed. Se você compara os dois arranjos antes de decidir, vale ler single-sig ou multisig, quando a complexidade se justifica, porque o descriptor é parte do custo de complexidade que o multisig cobra.

Onde o descriptor se encaixa

O descriptor é a peça que amarra tudo o que já explicamos sobre multisig. O conceito do arranjo e do quórum está em o que é multisig, e o passo a passo de montagem, no qual o descriptor aparece como saída obrigatória, está no guia como montar uma carteira multisig 2-de-3. O ritual de guardar as seeds, por sua vez, é o assunto de como fazer backup da sua seed phrase, e o descriptor é o backup que deve andar ao lado dele.

Por que isso te torna mais soberano

Entender o descriptor muda a forma como você encara a própria custódia. A carteira deixa de ser uma caixa-preta de uma marca e passa a ser um arranjo que você mesmo pode reconstruir em qualquer software compatível, desde que tenha as duas metades do backup, o segredo das seeds e o mapa do descriptor. Essa é a diferença entre confiar que um aplicativo específico continuará existindo e ter o controle real da própria recuperação.

Na Fugazzi Research operamos multisig próprio verificado contra full node próprio e já reconstruímos carteira a partir do descriptor em teste de recuperação real. Escrevemos sobre o arquivo que efetivamente salvaria os nossos fundos, não sobre teoria de whitepaper. Se a sua estrutura de custódia envolve valores relevantes ou um plano de herança, um teste de recuperação conduzido com método é o que separa a segurança que existe no papel da que existe de fato.

Perguntas frequentes sobre wallet descriptor

Perder o descriptor significa perder os bitcoins?

Não necessariamente, desde que você ainda tenha todas as seeds. Com todas as seeds e o conhecimento do arranjo, tipo de script e caminhos de derivação, é possível recalcular todas as chaves públicas e remontar o descriptor. O perigo real aparece na combinação de perder o descriptor e perder uma das chaves, porque aí a chave pública que faltava se torna impossível de recuperar.

O descriptor é secreto como a seed?

Não no mesmo grau. O descriptor guarda apenas chaves públicas, então quem o obtém consegue ver o seu saldo e os seus endereços, o que é uma exposição de privacidade, mas não consegue gastar nada. A seed, ao contrário, permite gastar. Por isso o descriptor pode ter cópias em lugares onde uma seed jamais deveria estar, contanto que você aceite o custo de privacidade.

Toda carteira precisa se preocupar com descriptor?

Na prática, a preocupação explícita nasce com o multisig e com configurações fora do padrão. Numa carteira de chave única comum, a própria seed e o caminho de derivação padrão bastam, e a carteira cuida do resto nos bastidores. Quanto mais o seu arranjo se afasta do trivial, mais o descriptor deixa de ser um detalhe técnico e vira parte central do backup.