413 / 736HEARN

Mike Hearn

Programador bitcoinj e autor de propostas de rede e pagamentos

Mike Hearn ajudou a desenvolver bitcoinj e propôs formas de comunicação entre carteiras, nós e comerciantes. O seu trabalho mostra o que acontece por trás de um pagamento comum em bitcoin e por que motivo diferentes avisos de receção não significam o mesmo.

Mike Hearn é um programador Bitcoin e coautor de vários BIP, documentos que descrevem propostas de soluções técnicas. Participou na biblioteca bitcoinj e em métodos para verificar ligações, selecionar transações relevantes e trocar mensagens durante um pagamento. Acompanhar o percurso entre uma carteira no telemóvel e a loja ajuda a compreender o seu contributo.

Quem desenvolve uma carteira Bitcoin não tem de escrever de raiz todo o código de comunicação. Pode usar uma biblioteca: um conjunto de funções já preparadas sobre as quais construir a aplicação. bitcoinj é uma dessas bibliotecas. O seu ficheiro AUTHORS inclui Mike Hearn entre muitos colaboradores e remete para o histórico de alterações no Git. Assim é possível identificar contributos concretos. Isso não significa que Hearn tenha escrito todas as funções sozinho ou que dirija atualmente o projeto inteiro. [1]

bitcoinj é uma biblioteca Java que permite gerir uma carteira e enviar ou receber transações sem instalar Bitcoin Core localmente. Num telemóvel, é útil o modo SPV, abreviatura de Simplified Payment Verification: trabalha com cabeçalhos de blocos e transações relevantes para a carteira, em vez de verificar integralmente todas as transações. Poupa assim dados e recursos do dispositivo. A documentação também descreve uma verificação completa experimental. São modos diferentes; funcionar de forma mais leve não significa executar a mesma validação de todas as regras, apenas mais depressa. [2]

Imaginemos um portátil que sai do modo de suspensão. A ligação a outro nó pode parecer aberta apesar de já não funcionar. O BIP 31 de Hearn permite enviar um ping com um nonce, aqui um número que identifica um pedido específico. O outro nó devolve esse número numa mensagem pong. Nas versões de protocolo superiores a 60000, é possível associar respostas a pedidos e medir o tempo de resposta. Verifica-se a comunicação: uma resposta, por si só, não prova a honestidade do nó nem a validade de um pagamento. [3]

Porquê descarregar transações que nada têm a ver com a carteira? O BIP 37, de Hearn e Matt Corallo, descreve um filtro Bloom, uma ferramenta compacta que seleciona possíveis correspondências. filterload define o filtro, filteradd acrescenta um elemento e filterclear remove o filtro. Pode passar uma transação sem relação com a carteira; isso é um falso positivo. Um filtro mais preciso reduz o tráfego, mas pode facilitar ao outro nó a associação de transações ao endereço IP da carteira. Poupar dados não protege automaticamente a privacidade. [4]

O telemóvel precisa de saber se uma transação recebida pertence a determinado bloco. A mensagem merkleblock do BIP 37 fornece dados para uma prova de Merkle: algumas impressões digitais dos dados, ou hashes, permitem verificar a ligação entre a transação e a impressão conjunta no cabeçalho do bloco. Não é preciso descarregar o bloco inteiro. A prova, contudo, não exclui a possibilidade de o outro nó ter escondido outras transações. SPV também não substitui a validação completa. A documentação de bitcoinj explica o perigo de um atacante controlar todas as ligações da carteira e decidir o que ela pode ver. [4] [5]

Numa compra, é necessário conhecer o valor e o destinatário. O BIP 70, de Gavin Andresen e Hearn, introduz PaymentRequest para esse fim. A mensagem inclui os detalhes do pagamento: saídas que indicam onde a transação deve atribuir os fundos, o montante e um eventual prazo de validade. Certificados X.509 podem autenticar a identidade do comerciante, à semelhança dos servidores web. Mas o protocolo também admite pki_type none, um pedido sem essa autenticação. O formato do pedido de pagamento, por si só, não comprova a identidade certificada da loja. [6]

Se o pedido indicar um servidor de pagamento, a carteira envia-lhe uma mensagem Payment depois da sua autorização. A resposta PaymentACK pode informar que a loja aceitou o pagamento para processamento. É útil para o cliente, mas continua a ser uma declaração do servidor do comerciante, não uma prova de confirmação num bloco. Da mesma forma, refund_to apenas indica para onde a loja pode enviar um reembolso; o campo não devolve dinheiro por si só. A aplicação deve distinguir as mensagens sobre um pagamento do movimento efetivo dos fundos. [6]

Um guia antigo pode dar a entender que o procedimento descrito funciona em todo o lado. O registo identifica o BIP 70 como Deployed, ou seja, implementado. Contudo, as notas de Bitcoin Core 0.20.0 documentam a remoção completa do seu suporte nesse programa. Não há contradição: uma especificação usada no passado não tem necessariamente suporte em todos os clientes atuais. O trabalho de Hearn ajuda a compreender a evolução das carteiras; a utilização prática exige também verificar as funções do programa concreto e da sua versão. [6] [7]

Para ter uma visão mais completa, leia este verbete junto com Jeff Garzik, Gloria Zhao, Merkle Tree. Também há referências a este verbete em Jeff Garzik, Gloria Zhao.

DOC · 001bitcoinj — recorded contributorsDocumentação DOC · 002bitcoinj — library and verification modesDocumentação DOC · 003BIP 31 — Pong messageDocumentação DOC · 004BIP 37 — connection Bloom filteringDocumentação DOC · 005bitcoinj — security modelDocumentação DOC · 006BIP 70 — Payment ProtocolDocumentação DOC · 007Bitcoin Core 0.20.0 — BIP70 removalDocumentação
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento