Até 2012, fazer backup de uma carteira era uma tarefa que nunca terminava. O programa original guardava cem chaves prontas num arquivo e gastava uma de cada vez; depois da centésima, o backup feito no primeiro dia já não continha as chaves novas, e quem confiava nele descobria isso da pior forma. Resolver esse problema é a razão de existir das doze palavras.
A proposta veio em fevereiro de 2012, de Pieter Wuille, e se chama BIP-32. A ideia é simples de enunciar: em vez de sortear cada chave, sorteia-se uma única semente e derivam-se todas as outras a partir dela, sempre pelo mesmo caminho. Um backup feito hoje vale para as chaves de daqui a dez anos, porque elas já estão determinadas — só não foram calculadas ainda.
O primeiro passo pega a semente de 512 bits da aula anterior e a passa por HMAC-SHA-512. Saem sessenta e quatro bytes, cortados ao meio: os trinta e dois da esquerda são a chave privada mestra, e os trinta e dois da direita são uma coisa nova, o código de cadeia. Esse segundo pedaço é o que impede que conhecer uma chave filha diga algo sobre as irmãs.

Derivar um filho é uma conta só: junte os dois, acrescente o número do filho, passe pela mesma função. Sai uma chave privada nova e um código de cadeia novo, prontos para gerar netos. É uma árvore de bilhões de chaves em que qualquer galho é recalculável a partir da semente, e nenhum precisa ser guardado.
Dessa estrutura nasce a peça mais útil de todas, a chave estendida. A versão privada se escreve xprv e deriva tudo. A versão pública se escreve xpub e deriva apenas as chaves públicas — endereços, portanto — sem nenhuma capacidade de gastar. Uma loja pode instalar o xpub no servidor, gerar um endereço novo para cada cliente e não ter, dentro daquela máquina, nada que permita mover uma moeda.

Essa comodidade cobra uma precaução. Um xpub revela todos os endereços que aquela conta terá, para sempre, e portanto todo o histórico e todo o saldo. Ele não gasta, mas conta tudo. Mandar um xpub a alguém é abrir o extrato inteiro, e não há como fechá-lo depois.
Há ainda uma armadilha matemática de verdade, e é dela que vem o apóstrofo dos caminhos de derivação. Na derivação comum, quem tiver o xpub de um pai e conseguir uma única chave privada filha consegue deduzir a chave privada do pai — e, com ela, a família inteira. A derivação endurecida corta esse caminho de volta: ela usa a chave privada do pai no cálculo, e por isso um xpub simplesmente não consegue produzir filhos endurecidos.

Agora o caminho deixa de ser feitiço. Em m/84'/0'/0'/0/5, o m é a raiz. O 84 com apóstrofo é o propósito, que diz qual padrão de endereço será usado e é o assunto da próxima aula. O 0 seguinte é a moeda, e Bitcoin é zero. O terceiro número é a conta, o que permite separar finanças pessoais das do negócio dentro da mesma semente. Os três primeiros níveis são endurecidos, sempre, exatamente pelo motivo do parágrafo anterior.
Os dois últimos não são, por uma razão prática. O quarto nível vale 0 para os endereços que você entrega a quem vai pagar e 1 para os de troco, que a carteira cria sozinha; o quinto é um contador que anda de um em um. Como esses dois níveis são comuns, o xpub da conta calcula todos eles — que é o que a loja do exemplo precisa.
Um detalhe do dia a dia fecha a aula. Ao restaurar uma semente, a carteira não varre a árvore inteira: ela procura os endereços em ordem e para depois de encontrar vinte seguidos sem nenhum movimento. Esse limite de vinte é convenção, e quem gerou manualmente um endereço muito à frente do contador pode ver o dinheiro sumir da tela sem ter sumido da blockchain.
Falta explicar o primeiro número do caminho, o tal do propósito. É ele que decide se a mesma semente vai mostrar endereços começando com 1, com 3 ou com bc1 — e por que duas carteiras honestas exibem saldos diferentes para as mesmas doze palavras. Na próxima aula, os padrões 44, 49, 84 e 86.