Até agora nesta série cobrimos o que é multisig e qual limiar escolher. Ambos artigos descreviam o comportamento de uma carteira multisig — m de n chaves assinam, a chain checa o limiar, o dinheiro se move. Nenhum disse muito sobre como a carteira é de fato montada por baixo. Isso é este artigo.
A versão curta: quando o SSP cria uma carteira pra você, ele não só gera duas chaves aleatórias e dá o serviço por feito. Ele as gera de um jeito que segue um padrão documentado chamado BIP48, de modo que a carteira resultante é interoperável, recuperável em software diferente do SSP, e previsível para inspecionar on-chain. Este é o artigo que explica o que é o BIP48, por que ele existe, e por que "essa carteira usa BIP48" é uma das frases mais chatas e mais importantes em multisig.
TL;DR
- Um caminho de derivação é o trajeto de uma única frase semente até uma chave específica (e endereço) numa carteira. Caminhos padronizados como BIP44 / BIP48 deixam softwares de carteira diferentes chegarem nas mesmas chaves a partir da mesma seed.
- BIP48 é a spec específica para carteiras multisig. Ela diz: aqui está o caminho de derivação canônico para as
mchaves que compõem uma carteira 2-of-3, 3-of-5, etc., através dos principais tipos de script de saída. - O SSP usa BIP48. Isso significa que as duas seeds que sua carteira SSP gerou são usáveis a partir de qualquer outra carteira compatível com BIP48 (Sparrow, Electrum, descriptors do Bitcoin Core) — não só do SSP.
- BIP48 corrige um problema que a spec anterior de multisig (BIP45) tinha: ela separa de forma limpa as chaves para tipos de script diferentes (legacy, P2SH-wrapped SegWit, native SegWit, Taproot), assim uma seed phrase pode segurar todas elas sem colisão.
- Você não precisa lidar manualmente com caminhos de derivação pra usar o SSP. Você deveria saber que eles existem pra que "recuperação de carteira" não pareça mágica — e pra entender ao que sua seed realmente mapeia.
Um passeio de 30 segundos pelos caminhos de derivação
Antes de o BIP48 ter qualquer significado, a maquinaria por baixo precisava existir. Essa maquinaria é o BIP32: carteiras hierarchical deterministic (HD). A ideia central é que uma chave mestra — derivada de uma seed phrase — pode produzir uma árvore infinita de chaves filhas, de forma determinística. Caminhe um trajeto específico pela árvore e você sempre chega na mesma chave filha. Caminhe outro e você chega em outra.
Os caminhos têm essa cara:
m / purpose' / coin_type' / account' / change / index
Por exemplo, o caminho BIP44 m / 44' / 0' / 0' / 0 / 0 chega ao primeiro endereço de recebimento da primeira conta do Bitcoin sob as regras BIP44. Troca o coin_type pra 60' e você está no espaço do Ethereum; troca o purpose pra 84' e você está no espaço BIP84 (native SegWit); e assim por diante. A aspa simples (') é derivação hardened — a filha não pode ser invertida de volta à pai. Cada segmento depois da mestra é um número de 32 bits, particionado por convenção.
Essa é a parte que normalmente passa batido: o caminho é metadata, não um segredo. Qualquer um que saiba seu caminho e sua chave privada (ou chave estendida) pode derivar os mesmos endereços. O caminho diz pra carteira onde olhar. A seed diz o que tem lá.
Pra uma revisão amigável do que a própria seed é, o post de seed phrase best practices é pré-requisito.
O que o BIP48 especifica
O BIP48 vive em m / 48' / coin_type' / account' / script_type' / change / index. A adição interessante é script_type' — o penúltimo segmento.
Esse segmento codifica que tipo de output multisig o caminho serve:
0'→ P2SH (multisig legacy)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ multisig equivalente a Taproot (por emendas BIP48)
Isso importa porque, na prática, o mesmo conjunto de cosigners m-of-n produz endereços diferentes on-chain dependendo de qual script de output é usado. Sem BIP48, uma carteira poderia usar silenciosamente um tipo, o software de recovery poderia assumir outro, e o resultado são duas carteiras que parecem deveriam derivar as mesmas moedas — mas não derivam, porque estão computando endereços diferentes.
O BIP48 também fixa o segmento purpose' em 48', então os caminhos multisig não podem colidir com caminhos single-sig BIP44/BIP49/BIP84. Uma única seed pode segurar uma carteira single-sig em BIP84 e uma carteira multisig 2-of-2 em BIP48, sem interferência. Cada uma vive na sua própria subárvore.
Além do caminho em si, o BIP48 especifica como as chaves públicas dos cosigners ("xpubs") devem ser ordenadas ao se construir o output multisig. A regra canônica é ordenação lexicográfica das chaves públicas antes de entrarem no redeem script. Isso remove ambiguidade — toda carteira em conformidade com BIP48 que construa a partir dos mesmos xpubs computa o mesmo endereço. Sem essa regra, duas carteiras poderiam combinar as mesmas chaves em ordens diferentes e cair em endereços diferentes com a mesma regra de redeem.
Se quiser ler a spec na íntegra, ela vive no repo de Bitcoin BIPs (bips/bip-0048.mediawiki).
Como o SSP usa o BIP48 na prática
Quando você configura uma carteira SSP, duas seed phrases são geradas — uma na extensão do navegador, uma no app móvel SSP Key. Cada seed phrase corresponde a uma chave privada mestra. A partir de cada mestra, o SSP deriva o caminho BIP48 pra chain relevante (Bitcoin, Ethereum, Flux e o resto do conjunto suportado pelo SSP) em script_type' = 2' (native SegWit no Bitcoin; formas canônicas equivalentes nas outras chains onde aplicável).
As xpubs dos dois assinantes são então trocadas. Cada lado tem agora o mesmo conjunto de duas xpubs, ordenadas lexicograficamente pelo BIP48. A partir desse par, cada lado computa independentemente o mesmo endereço. As duas metades nunca compartilham uma chave privada — só chaves públicas se movem entre dispositivos.
Quando você recebe dinheiro, o endereço mostrado é o endereço derivado por BIP48 calculado a partir das duas xpubs. Quando você gasta, cada dispositivo assina a mesma transação com sua própria chave privada. O redeem script on-chain referencia as duas chaves públicas; a rede checa as duas assinaturas. Esse é o protocolo inteiro.
A razão de isso importar num cenário de recuperação: se o SSP, como produto, sumisse amanhã, você ainda teria duas seed phrases em conformidade com BIP48. Carregar as duas no Sparrow (ou em qualquer outra carteira capaz de multisig que suporte os caminhos BIP48 que o SSP usa) reconstrói a mesma carteira, nos mesmos endereços, com plena capacidade de gasto. A carteira não vive dentro do SSP — ela vive on-chain, e as seeds mais a spec do BIP48 são suficientes pra chegar nela de qualquer lugar.
Essa propriedade é boa parte de por que o self-custody-without-cold-storage trata uma carteira SSP 2-of-2 como uma carteira séria em vez de uma curiosidade de sabor custodial. Ela é recuperável a partir de padrões abertos.
Por que BIP48 em vez de BIP45 (e não BIP44)
A spec multisig anterior era a BIP45. Foi uma primeira tentativa honesta: m / 45' / cosigner_index' / change / index, com cosigner_index' codificando qual cosigner você é na carteira. Em retrospecto ela tinha dois problemas.
Primeiro, cosigner_index' cozinhava uma ordem dentro do próprio caminho. Isso significava que a ordem em que os signatários eram adicionados afetava a derivação, o que tornava o setup conjunto frágil — erra a ordem e você deriva endereços diferentes dos do seu cosigner. O BIP48 resolve isso removendo o cosigner index do caminho de vez e deixando a ordenação lexicográfica das chaves públicas cuidar disso.
Segundo, BIP45 não separava por tipo de script. O mesmo caminho seria reusado quer a carteira usasse multisig P2SH legacy ou multisig SegWit-wrapped. Isso criava o mesmo problema de colisão-de-endereços-mas-não-são-as-mesmas-moedas descrito acima.
O BIP44, a spec HD mais geral, nunca pretendeu cobrir multisig. Tentar sobrecarregá-lo com caminhos multisig criava seus próprios conflitos. O BIP48 foi o conserto explícito: um purpose number dedicado, um slot de script-type explícito, e uma ordenação determinística das chaves. Hoje a maioria das carteiras multisig modernas converge nele; é o padrão de facto.
Pro histórico mais profundo de como isso conecta com o próximo capítulo de multisig — agregação Schnorr, em que múltiplas assinaturas comprimem em uma — o próximo artigo desta série, Schnorr signatures and multisig aggregation, pega o fio.
O que isso significa pra interoperabilidade
O teste mais limpo de "essa carteira multisig é de fato self-custodial?" é: posso recuperá-la sem o software dela? Se a resposta é sim — usando seeds documentadas, um caminho de derivação documentado e ferramentas padrão — a carteira é genuinamente sua. Se a resposta é não, a carteira tem elementos custodial escondidos.
A conformidade do SSP com BIP48 é o que permite a gente responder sim. As seed phrases são BIP39 (mnemônico padrão), a derivação é BIP48, a construção de endereço é canônica BIP48. Qualquer carteira que fale os mesmos padrões pode reconstruir a carteira.
Por isso a introdução Meet SSP Wallet enquadra o SSP como "self-custody com multisig 2-of-2" em vez de um serviço gerenciado. Os padrões por baixo são a razão pela qual esse enquadramento é honesto.
O que isso significa pra você
Três conclusões:
- Você não precisa decorar caminhos pra usar SSP. O número
m/48'/0'/0'/2'/0/0não é algo que um usuário normal deveria digitar. Mas saber que ele existe é o que torna "consigo recuperar essa carteira sem SSP" uma afirmação real em vez de marketing. - Suas duas seeds são interoperáveis. Se você um dia precisar recuperar numa carteira multisig de terceiros, BIP48 mais suas duas seeds BIP39 mais o
coin_typeda chain é a receita. O checklist de self-custody cita isso como o passo de ensaio por uma razão. - Uma carteira multisig que não usa BIP48 (ou similar) merece ser questionada. Se um produto não consegue te dizer exatamente como os endereços são derivados das suas chaves, isso não é self-custody — é custódia com passos extra. Conformidade com padrões é o que torna a afirmação "suas chaves, suas moedas" verificável.
