PaymentRequest

O PaymentRequest era a mensagem que permitia a uma carteira mostrar o nome de uma empresa em vez de uma sequência de caracteres. Ele tinha cinco campos, e os dois que importavam eram pki_type, com um dos valores none, x509+sha256 ou x509+sha1, e signature, a assinatura sobre os detalhes serializados. Para quem paga hoje, a lição sobrevive ao protocolo: um nome em uma tela de pagamento é tão confiável quanto quem o atestou.

Como funciona

Status: obsoleto. O Bitcoin Core incluiu o tratamento de PaymentRequest desde a versão 0.9.0 até que a versão 0.20.0 o removeu em 3 de junho de 2020, e nenhuma carteira mantida atualmente interpreta a mensagem.

Cinco campos, em ordem:

• payment_details_version, um número inteiro de 32 bits com valor padrão 1. Ele nunca foi incrementado.
• pki_type, uma sequência de caracteres com valor padrão "none". As alternativas eram "x509+sha256" e "x509+sha1".
• pki_data, que continha uma estrutura X509Certificates com o certificado de folha do comerciante em primeiro lugar e os certificados intermediários, se houvesse, depois dele.
• serialized_payment_details, obrigatório, a cadeia de bytes opaca descrita em outra entrada deste glossário.
• signature, os bytes que provam que tudo veio do titular do certificado.

O procedimento de assinatura tem um pequeno truque. O comerciante preenche todos os campos, deixa signature vazio, serializa a mensagem completa, calcula o hash dela, assina esse hash com a chave privada correspondente ao certificado de folha e depois escreve a assinatura no campo que acabara de deixar em branco. Um verificador esvazia o campo de novo, serializa outra vez e verifica. Simples, autossuficiente e dependente de nada além do certificado.

Essa dependência era o problema. Validar a cadeia exigia que a carteira tivesse um repositório de certificados raiz, que o software de desktop herdava do sistema operacional e que o software móvel muitas vezes tratava mal. Mesmo uma implementação correta provava apenas que alguma autoridade de certificação havia atestado um nome de domínio, e um repositório de raízes contém centenas de autoridades, qualquer uma das quais pode emitir para qualquer nome. A opção mais fraca disponível, x509+sha1, envelheceu especialmente mal: uma colisão prática de SHA-1 foi publicada em 23 de fevereiro de 2017, quatro anos depois de o BIP70 ser escrito.

Onde você o vê

Dois lugares ainda usam o nome PaymentRequest, e apenas um deles envolve bitcoin.

O primeiro é código e documentação arquivados, onde o tipo MIME do BIP71 application/bitcoin-paymentrequest marcava a resposta que o servidor de um comerciante retornava. O segundo é a plataforma web moderna, onde PaymentRequest nomeia uma API do navegador para pagamento com cartão e com métodos de pagamento guardados que não tem nada a ver com este protocolo. Um desenvolvedor que usa a palavra hoje quase certamente se refere à do navegador, e confundir as duas é o erro mais comum nas buscas por documentação antiga de bitcoin.

Para quem compra bitcoin, a conclusão é sobre como a identidade se associa aos pagamentos. As corretoras resolvem isso com contas e KYC, de modo que a plataforma sabe quem você é e você confia na reputação da plataforma. A autocustódia resolve isso fazendo você mesmo verificar o endereço. O BIP70 tentou uma terceira rota, tomando emprestado o sistema de certificados da web, e essa rota está fechada.

PaymentRequest vs PaymentDetails

O PaymentRequest é o envelope; o PaymentDetails é a carta dentro dele. Ler o envelope indica quem assinou e qual certificado essa pessoa usou, mas não o que está sendo pedido. Os valores, os scripts, a expiração e o memo estão todos na mensagem interna, que fica no envelope como uma cadeia de bytes não interpretada justamente para que a assinatura não seja invalidada por uma nova codificação. Uma carteira tinha que verificar o primeiro antes de confiar em qualquer coisa do segundo.