Gap Limit

Anna usa uma carteira, uma aplicação ou um dispositivo para receber e enviar bitcoin. Gerou antecipadamente muitos endereços de recebimento, os dados necessários para lhe enviar um pagamento, mas nunca usou alguns deles. Depois de restaurar a carteira, faltam pagamentos. Imagine uma pesquisa com limite 20: o endereço de índice 0 tem histórico, os índices seguintes 1–20 não, e o índice 21 recebeu um pagamento. O índice é apenas a posição do endereço na sequência; a numeração começa em zero. A pesquisa para depois da sequência vazia, antes do índice 21, e não encontra esse pagamento. Se surgisse um endereço usado na sequência examinada, o contador do intervalo recomeçaria. Portanto, o limite não significa que a carteira inteira só possa ter vinte endereços. [1] [6]

O que significa sem uso neste caso? Não significa um endereço sem dinheiro neste momento. Anna pode ter recebido um pagamento e gasto tudo depois. O saldo fica a zero, mas o histórico permanece e o endereço continua a contar como usado. Por isso, BIP 44 trabalha com o histórico, não apenas com o saldo atual. Tratar qualquer endereço vazio como nunca usado poderia interromper a recuperação cedo demais. Até um recebimento gasto há muito tempo ajuda a verificar uma carteira restaurada. [1]

BIP 44 é um padrão que descreve a organização das contas e dos endereços numa carteira hierárquica, que organiza chaves e endereços numa árvore com diferentes ramos. A regra Address gap limit estabelece uma fronteira de 20 para a pesquisa no ramo externo de recebimento, a sequência de endereços destinada a receber pagamentos. O programa deve avisar ao gerar um endereço além dessa fronteira. É uma convenção de recuperação, não uma regra de consenso que determina se a rede aceita uma transação. Outras carteiras podem ter configurações ou procedimentos de pesquisa diferentes. A regra também não recomenda reutilizar indefinidamente o mesmo endereço de recebimento. [1]

A carteira original pode conhecer endereços gerados muito adiante na sequência. Ao restaurar apenas uma cópia das chaves, o novo programa pode não saber até onde tinha ido. Electrum avisa expressamente: endereços além do Gap Limit podem não ser encontrados automaticamente durante a recuperação normal. A documentação descreve como soluções aumentar o limite ou derivar mais endereços até à posição usada. As configurações adequadas dependem, contudo, do programa e do tipo de carteira. O valor padrão de 20 na FAQ refere-se ao Electrum 2.0 e não é universal para todas as carteiras atuais. [2]

Podemos imaginar a carteira como uma árvore organizada. As contas separam grupos de fundos, e cada conta pode conter diferentes ramos de endereços. Em BIP 44, change=0 identifica o ramo de recebimento e change=1 o de troco próprio, a quantia que fica com o remetente depois do pagamento. A procura de contas começa na conta 0 e examina o seu ramo externo. Se encontra histórico, segue para a próxima; a primeira conta sem histórico interrompe a procura de contas. Por isso, o padrão indica que não se deve criar uma conta nova se a anterior não tiver histórico. Um intervalo vazio num ramo e uma conta vazia saltada são problemas diferentes. Aumentar um limite não determina, por si só, quais outras contas o programa pesquisará. [1]

BIP 32 descreve a derivação determinística de chaves: os mesmos dados iniciais e o mesmo caminho produzem as mesmas chaves. Uma Derivation Path é o percurso nessa árvore; juntamente com o tipo de script, ou seja, as regras de gasto, determina os endereços acompanhados. A Seed Phrase correta, as palavras da cópia de segurança, é assim apenas parte da informação necessária. Em BIP 39, uma passphrase opcional também entra no cálculo da seed, o segredo inicial usado para derivar as chaves. A passphrase é um texto secreto adicional, distinto da palavra-passe da aplicação. Outra passphrase conduz a outra carteira; aumentar Gap Limit não corrige isso. Uma chave privada é um valor numérico secreto que a carteira usa para criar uma assinatura digital que autoriza um gasto. Para leitores avançados, um xpub é uma chave pública estendida para derivar outras chaves públicas. Ajuda a acompanhar endereços e pagamentos, mas não permite, por si só, autorizar gastos. Não consegue, sozinho, atravessar um passo hardened, que exige a chave privada do elemento pai. Procurar mais longe não fornece essa capacidade em falta. [4] [5] [6]

Bitcoin Core 29.0 disponibiliza importdescriptors através de RPC, a interface de programação do nó. Um descriptor descreve como as chaves formam condições de gasto e os endereços a acompanhar. range define os índices a derivar; não é uma regra de paragem após um intervalo sem uso. Quando o descriptor está ativo, next_index define o próximo índice para gerar endereços. timestamp determina desde quando procurar transações. now destina-se a saídas que sabemos nunca terem sido usadas; não substitui a recuperação de pagamentos antigos. A documentação inclui também blocos até duas horas antes do timestamp mais antigo dos descriptors importados e o Mempool, o conjunto local de transações não confirmadas. Assim, mesmo um endereço derivado corretamente pode faltar na visão geral se o período relevante não tiver sido pesquisado. [3]

Voltemos a Anna. Se guardou um endereço de recebimento conhecido ou um registo de pagamento da carteira original, pode verificar se a nova os encontrou. Convém comparar também os recebimentos já gastos, não apenas o saldo final. Uma pesquisa mais longa pode encontrar histórico omitido, mas exige tempo e mais consultas. Se usar um servidor remoto, pode revelar-lhe mais endereços relacionados. A pesquisa por si só não transfere dinheiro nem altera a blockchain. Se o histórico continuar diferente, é preciso verificar os dados da cópia, a conta, o caminho, o tipo de endereço e a disponibilidade dos dados históricos, em vez de apenas aumentar o limite. Encontrar um endereço não prova que toda a recuperação esteja completa. [1] [2] [4]