Watch-only Wallet

A Alice guarda as chaves numa carteira de hardware e quer confirmar um pagamento pelo telemóvel. Transfere para ele a configuração pública da carteira, não as palavras de recuperação. A aplicação reconhece então os endereços correspondentes e procura os seus pagamentos na rede. A Alice vê uma entrada de 20 000 sat, as menores unidades do bitcoin, e as respetivas confirmações, embora o dispositivo de assinatura esteja desligado em casa. O telemóvel não ganhou autorização para gastar esse dinheiro. Do mesmo modo, um comerciante pode dar à contabilista uma visão dos pagamentos sem lhe entregar as chaves. O importante é o que foi realmente importado: introduzir uma Seed Phrase, as palavras que recuperam as chaves, eliminaria essa separação. [12]

É possível adicionar o endereço público de outra pessoa a uma aplicação de observação. O valor no ecrã não prova que o utilizador o pode gastar, muito menos que consegue pagar todas as suas dívidas. A aplicação soma os UTXO encontrados: saídas de pagamentos anteriores que ainda não foram gastas. Só encontra o que corresponde aos dados importados e ao histórico disponível. Endereços em falta, uma pesquisa por terminar ou um servidor pouco fiável podem dar uma visão incompleta. Um zero no ecrã não significa, por si só, bitcoins perdidos; primeiro verifique o âmbito da observação e a fonte dos dados. [8] [9]

Quando a Alice quer pagar, a aplicação escolhe UTXO disponíveis e prepara destinatário, montante e taxa. Pode devolver à própria carteira a parte não utilizada de uma entrada, o chamado troco ou change. Estes dados podem viajar numa PSBT, o formato de transação Bitcoin parcialmente assinada definido no BIP174. O dispositivo separado recebe assim o necessário para assinar sem ter uma base UTXO própria. A Alice deve confirmar no seu ecrã de confiança o verdadeiro destinatário, o montante, a taxa e o troco. Uma aplicação comprometida pode preparar um pagamento diferente do pretendido. Também importa o sighash, que determina as partes da transação abrangidas pela assinatura. Só após verificar e assinar se transmite a transação final, em conformidade com a proposta aprovada e as regras da carteira. [2] [10]

Uma chave pública estendida, ou xpub, permite derivar mais chaves públicas numa ramificação da carteira; sozinha não assina pagamentos. Porém, quem a obtiver com as regras da carteira pode relacionar endereços alcançáveis, pagamentos passados e futuros e saldos. Isso revela muito mais do que um endereço para um único recebimento. Um servidor externo pode construir uma visão semelhante a partir de consultas repetidas da aplicação. Um Full Node próprio, que verifica a blockchain, limita essa partilha; uma ligação cifrada ou privada não esconde as consultas do servidor de destino. Exporte apenas a conta necessária, limite as cópias e proteja as etiquetas que associam endereços a nomes ou finalidades dos pagamentos. [1] [13] [14]

As secções seguintes são uma referência técnica para configuração e recuperação. Um script estabelece condições de gasto; um Output Descriptor regista essas regras e os dados necessários para derivar endereços. Uma HD Wallet cria uma árvore de chaves a partir de um seed, os dados secretos iniciais usados para derivar essas chaves. A derivação non-hardened gera mais chaves públicas a partir de um xpub, enquanto a hardened requer uma chave privada. Multisig acrescenta um número definido de assinaturas necessárias. Importar um endereço acompanha apenas o seu script, não futuros endereços de receção ou de troco. Uma chave pública abrange diferentes tipos de script apenas se o programa os derivar explicitamente. Um xpub de conta deriva descendentes non-hardened, mas não define P2PKH, SegWit, Taproot, a ramificação interna ou o limiar de assinaturas Multisig. O descritor fornece esse contexto. Exporte-o da conta correta do dispositivo de assinatura, com a rede e o tipo de script certos; não adivinhe o caminho de derivação, a sequência de passos a partir da chave inicial. [1] [4] [7]

As carteiras HD costumam separar a receção /0/* da ramificação interna /1/* para o change, ou troco. Sem a ramificação interna, fundos podem parecer desaparecer depois de uma despesa. Um range pequeno, o intervalo de endereços derivados, pode ocultar recebimentos. next_index determina o próximo endereço a gerar; uma diferença entre dois programas pode levar à reutilização de endereços. Mantenha alinhados descritores ativos, intervalos e índices. Confirme o endereço de receção no ecrã do dispositivo de assinatura: software malicioso pode trocá-lo apesar de mostrar um saldo credível. [6] [9]

No Bitcoin Core, importdescriptors usa timestamp para definir o início da nova pesquisa. now ignora o histórico antigo; 0 pede uma pesquisa desde o Genesis Block. Também contam o intervalo range e a disponibilidade de blocos antigos. active determina se o descritor é usado para gerar novos endereços; internal identifica saídas internas da carteira, como o troco. Um nó com histórico podado, que apagou blocos antigos para poupar espaço, pode não conservar os blocos necessários. Um rescan apenas encontra transações existentes. Guarde a data ou altura da primeira utilização e compare a recuperação com endereços e transações conhecidos, não apenas com um zero no ecrã. [9] [10]

O BIP380 define uma linguagem para conjuntos de scripts de saída. O exemplo wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum contém tipo de script, impressão digital da chave mestra, caminho de origem, chave pública da conta, ramificação, índice variável e soma de verificação. Não é um dado válido para importar. Taproot usa tr() segundo o BIP386; o BIP389 admite vários caminhos numa expressão. A soma deteta erros de cópia, não confirma a identidade do autor. Um descritor com xprv contém uma chave secreta e não deve entrar num coordenador de observação. [4] [5] [6] [7]

O BIP32 descreve uma exceção importante: um xpub ascendente e a chave privada de um descendente obtido apenas por passos non-hardened permitem calcular a chave privada ascendente. O xpub sozinho não basta; a combinação é perigosa. Um passo hardened acima da conta exportada impede que o ataque atravesse essa fronteira. Nunca introduza xprv, seed ou chaves privadas na carteira de observação, na sua base ou nos ficheiros PSBT associados. [1]

Observar uma carteira Multisig exige o limiar de assinaturas, tipo de script, xpub de cada coassinante, origem e ordem das chaves e ambas as ramificações de endereços. Um único xpub não basta. Perder o descritor pode complicar a recuperação mesmo com seeds intactos; outra ordem ou estrutura envolvente do script pode gerar endereços diferentes. Confirme as regras e um endereço de exemplo em todos os dispositivos de assinatura. Guarde um descritor com soma de verificação ou uma configuração padrão, lembrando que revela as relações entre coassinantes. [4] [11]

Guarde separadamente das chaves privadas os descritores das duas ramificações, origens, rede, data ou altura de criação, intervalos, índices, etiquetas e regras Multisig. O BIP329 transporta etiquetas, não substitui o descritor nem o histórico. Teste a recuperação num perfil separado ou numa rede de teste: importe a configuração pública, pesquise o histórico, compare endereços antigos das duas ramificações e os UTXO esperados, prepare uma PSBT e assine-a no dispositivo previsto. Confirme o resultado antes de transmitir. Watch-only permite observar e preparar, mas não dá autorização para gastar. [3] [9] [12]