Multisig single-signer: como o SSP faz dois dispositivos parecerem uma carteira

Se você acompanhou esta série desde o que é multisig, conhece o protocolo: mais de uma chave privada precisa assinar antes de o dinheiro se mover. Você viu o seletor m-of-n, a montagem BIP48, o horizonte de agregação Schnorr, e a comparação com social-recovery. Tudo isso é a maquinaria. Este artigo é sobre a experiência.

A crítica histórica honesta ao multisig é que ele tem sido hostil de usar. Várias carteiras, troca manual de PSBT, software coordenador, festas de assinatura — o protocolo era sólido, mas a UX era um castigo. Single-signer multisig é a ideia de produto que conserta isso: uma carteira que usa uma regra de gasto multisig completa on-chain, mas se sente — pra pessoa que a usa — como uma carteira só com um botão só. O SSP é construído em torno dessa ideia.

TL;DR

• "Single-signer" não significa uma chave. Significa que o protocolo ainda tem m de n chaves, mas a UX de assinatura é colapsada em um fluxo único. O usuário assina em um lugar; a carteira lida com a coordenação entre dispositivos.
• O formato específico do SSP: uma extensão de navegador, um app móvel (SSP Key), uma identidade de carteira. Você clica em Send, confirma no celular, a transação é transmitida. Duas assinaturas acontecem; você experimenta uma.
• A vitória é que o benefício do limiar (resistência a roubo, sem ponto único de falha) é preservado enquanto o custo de coordenação cai quase pro nível da UX single-sig.
• O custo é que isso só funciona enquanto ambos os seus dispositivos estiverem alcançáveis. No momento em que a UX precisa expor a multi-natureza — recuperação, troca de dispositivo, restauração num terceiro — a abstração quebra, por design.
• Esse padrão é a coisa mais próxima de uma resposta "sem compromisso" pra self-custody solo em escala retail. É a aposta do SSP, e cada vez mais a aposta de cada produto multisig moderno (Coinbase Wallet, a história de custódia em evolução do Phantom, o fluxo smart-account do Safe no Ethereum).

O ideal single-signer: o que os usuários realmente querem

Se você pergunta a um usuário de self-custody o que ele quer, recebe respostas que se contradizem:

• "Quero minhas moedas seguras." — Implica multisig, hardware, redundância.
• "Quero assinar uma transação em cinco segundos." — Implica um único dispositivo, um toque.
• "Quero recuperar se perder algo." — Implica backups de seed, redundância.
• "Nunca mais quero escrever uma seed." — Implica custódia de chaves gerenciada pela plataforma.
• "Quero que seja barato." — Implica uma pegada on-chain mínima.

Esses objetivos não se alinham todos. A história do design de carteiras self-custody é a história de quais objetivos honrar e quais recusar educadamente. Carteiras de hardware honram segurança e recuperação ao custo da UX. Carteiras smart-contract honram UX e recuperação ao custo de alcance cross-chain. Hot wallets puras honram UX e barato ao custo de segurança.

Single-signer multisig é uma tentativa de honrar os cinco — parcialmente — separando semântica de protocolo da semântica de interface. A carteira ainda faz a dança multisig completa on-chain; o usuário simplesmente não precisa participar dessa dança mais de uma vez por transação.

Como o SSP entrega isso

A implementação específica do SSP, em português claro:

1. Na configuração, você instala a extensão de navegador e o app móvel (SSP Key). Cada um gera sua própria seed, que você faz backup separadamente (esse é o passo do checklist dos primeiros 1000). Os dois dispositivos trocam chaves públicas; a partir desse ponto, eles compartilham uma identidade de carteira no nível do protocolo.
2. Na assinatura cotidiana, você clica em Send na extensão do navegador, revisa a transação e aprova. A extensão constrói uma transação parcialmente assinada e empurra uma notificação pro seu celular. O app móvel mostra os detalhes da transação, você toca em aprovar e o app produz a segunda assinatura. A extensão combina ambas as assinaturas e transmite. Tempo total: cerca de 8 segundos quando ambos os dispositivos estão na sua frente.
3. No recebimento, o endereço mostrado é o endereço multisig derivado por BIP48 das duas xpubs. Você escaneia ou copia; o remetente não vê nada de incomum. Do lado dele parece qualquer outro endereço cripto.
4. No acerto de contas, a carteira te mostra saldos, histórico, fees e tal, identicamente a uma carteira single-sig. Não há uma "tela multisig" separada. A forma do protocolo é invisível durante o uso normal.

A escolha de design chave é que a segunda assinatura é a única multi-natureza com a qual o usuário tem que se importar. Setup são dois dispositivos, assinatura é um toque a mais, e essa é toda a superfície do protocolo multisig do ponto de vista do usuário.

Um detalhe pequeno mas importante: a extensão de navegador SSP e o SSP Key não estão co-localizados. Estão em OSes diferentes, hardware diferente, superfícies de ataque diferentes. É isso que faz o setup de duas assinaturas ser uma barreira real contra roubo, não só uma lombada de UX. (Desempacotamos isso na peça dos sete modos de falha e em O que é multisig 2-of-2.)

O que o usuário nunca vê

Muito trabalho vai em manter o usuário longe de ter que lidar com encanamento multisig. Especificamente:

• PSBT (Partially Signed Bitcoin Transactions) são as estruturas de dados volumosas que se movem entre os dispositivos cofirmantes. Num setup multisig tradicional você copia e cola elas manualmente. O SSP serializa e transmite via seu próprio canal de coordenação; o usuário vê uma notificação, não uma string base64.
• A troca de xpubs de cosigner é um evento único de configuração. Em multisig tradicional, você importa xpubs de cada cosigner explicitamente. O SSP embrulha isso no fluxo de pareamento na configuração; você confirma um QR code ou um código de seis dígitos e nunca toca o material subjacente.
• Estimativa de fee, tratamento de troco e rotação de endereço são tratados pela carteira exatamente como carteiras single-sig fazem, apesar de a carteira em si ser multisig por baixo.
• O redeem script — o script BIP48-canônico descrevendo a regra multisig — é construído pela carteira automaticamente. Usuários não veem, não aprovam linha por linha, não precisam saber que existe. (Eles podem vê-lo num block explorer se olharem, que é a propriedade "mostre seu trabalho" mais limpa das carteiras multisig.)

Toda essa abstração é trabalho necessário, mas também é o risco — cada vez que o protocolo é escondido do usuário, a carteira assume responsabilidade por acertar a parte escondida. O trabalho de auditoria do SSP (Halborn) é em grande parte sobre exatamente esses caminhos de código invisíveis.

Quando deixa de parecer single-signer

A abstração não é perfeita, e é importante saber onde ela quebra. A UX single-signer aguenta enquanto ambos os dispositivos estiverem disponíveis. As rachaduras aparecem quando um não está:

• Troca de dispositivo. Quando você troca de celular, o novo dispositivo precisa ser repareado. Esse é um passo de coordenação multisig pontual que de fato é visível — a carteira te guia mostrando os dois dispositivos um ao outro de novo.
• Recuperação de seed. Se um dispositivo é destruído, você o recupera da seed phrase pra um novo dispositivo, depois re-pareia. O fato de você ter duas seeds (uma por dispositivo) se torna visível nesse momento de um jeito que não era durante o uso normal.
• Recuperação cross-software. Se um dia você carregar suas duas seeds SSP numa carteira multisig de terceiros (Sparrow, Electrum, etc.), todo o encanamento multisig se torna visível — isso é uma feature, não um bug, porque é o que prova que sua carteira é interoperável, mas não é a UX SSP.
• Gastar quando um dispositivo está offline. A carteira não pode cofirmar sem ambos os dispositivos; isso é o protocolo. Você verá um estado "aguardando a segunda assinatura" até o outro dispositivo voltar online.

Os três primeiros são infrequentes o suficiente pra não degradarem realmente a UX média. O quarto é o ponto de fricção mais comum — e o ponto de fricção correto. Se a carteira te deixasse gastar sem o segundo dispositivo, ela não seria mais uma carteira 2-of-2. Essa fricção é a segurança; você não consegue desfazer dela por engenharia sem tirar a propriedade pela qual você estava pagando.

Projetando ao redor da UX single-signer

Três princípios de design que o SSP — e outros produtos multisig modernos — seguem pra manter essa abstração apertada:

1. Os dois cosigners precisam viver em superfícies de ameaça diferentes. Uma carteira que põe as duas chaves cofirmantes no mesmo OS não está realmente entregando o benefício de segurança; só espalha uma única superfície de ataque por duas fechaduras. A divisão do SSP entre extensão de navegador e app móvel força isso naturalmente.
2. O canal de coordenação precisa ser não-forjável. O PSBT que uma extensão de navegador envia pro app móvel precisa estar criptograficamente atado à carteira certa e à transação certa; senão a abstração vira sua própria superfície de ataque. O SSP assina e valida esse material no nível do protocolo.
3. O contrato com o usuário precisa ser honesto sobre o que está escondido. Carteiras que dizem "experiência single-signer totalmente trustless" sem explicar o que acontece na recuperação preparam usuários pra uma surpresa desagradável. O onboarding do SSP percorre explicitamente as duas seeds, os dois backups e os dois cenários de recuperação — a abstração é escondida durante o uso mas exposta durante o onboarding pra não te emboscar depois.

Carteiras de account abstraction no Ethereum têm uma quarta ferramenta: a camada smart-contract. Com ERC-4337, uma carteira pode absorver fees de gás, bater transações em lote, e apresentar uma UX ainda mais "single-signer-like" e implementar multisig por baixo. O SSP não tem essa camada no Bitcoin (sem smart contracts), então a abstração se apoia mais em engenharia de UX do que em absorção chain-side. Ambos caminhos são válidos; o do Ethereum é mais flexível ao custo de ser específico de chain, o do SSP é mais portável ao custo de mais trabalho de UI.

O que isso significa pra você

Três conclusões:

1. A experiência "parece uma carteira só" é a feature de manchete, não o multisig em si. Se seu amigo perguntar "o SSP é uma carteira multisig?", a resposta tecnicamente verdadeira é sim, mas a resposta útil é "é uma carteira de 2 dispositivos onde um toque no celular confirma um gasto". Isso captura o que as pessoas realmente sentem.
2. A fricção que você vê está fazendo trabalho real. Toda vez que o SSP te pede pra confirmar no celular, ele está aplicando o protocolo que impede um laptop comprometido de esvaziar seus fundos. Essa fricção é a razão principal de você estar usando uma carteira 2-of-2 em vez de uma hot wallet, pra começar.
3. Trate a abstração como um contrato, não como mágica. O artigo final desta série, Modos de falha multisig e como o SSP os mitiga, percorre o que acontece quando cada peça da abstração quebra — perda de dispositivo, comprometimento de chave, indisponibilidade do servidor de assinatura. Leia uma vez. A abstração é bem projetada, mas entender os modos de falha é o que te faz o tipo de usuário de self-custody pro qual toda esta série existe.