Dados de comerciante do PP

Associar um pagamento a um pedido é o problema pouco glamouroso que todo checkout precisa resolver, e o bitcoin torna isso mais difícil porque uma transação não carrega número de fatura. O BIP70 resolvia isso entregando à carteira do cliente um cookie e pedindo que ele voltasse. Hoje os comerciantes resolvem o mesmo problema com um endereço de uso único por pedido, o que é ao mesmo tempo mais simples e mais privado.

Como funciona

Status: histórico. Os dados de comerciante eram o campo 7 do PaymentDetails e o campo 1 da mensagem Payment que voltava, e desapareceram com o resto do BIP70 quando o Bitcoin Core 0.20.0 foi lançado em 3 de junho de 2020.

A opacidade era o ponto. A carteira era instruída a tratar os bytes como sem significado e devolvê-los sem alteração, o que permitia a cada comerciante inventar seu próprio esquema sem que ninguém mais precisasse entendê-lo.

Dois esquemas eram comuns. Uma chave de busca curta, digamos um identificador de pedido de 16 bytes, mantinha a solicitação pequena e empurrava o trabalho para o banco de dados do comerciante. Um bloco autocontido guardava o carrinho inteiro e permitia que o servidor permanecesse sem estado, ao custo do tamanho.

O segundo esquema tem um furo sobre o qual a especificação alertava. Esses bytes voltam de um software que o comerciante não controla, então tudo o que se lê deles é entrada fornecida por um atacante. Uma loja que guardasse ali um preço ou um código de desconto e confiasse na cópia devolvida teria construído para si um gerador de cupons. O remédio é o habitual para estado que faz ida e volta: anexar um código de autenticação de mensagem e verificá-lo antes de ler um único campo.

O tamanho importava mais do que parece. A solicitação assinada inteira precisava chegar ao cliente, e representá-la como código QR impõe um teto rígido: o maior símbolo, a versão 40 no nível mais baixo de correção de erros, comporta 2.953 bytes de dados binários. Esse teto é a razão pela qual o BIP72 definiu o parâmetro r=, para que um link curto pudesse apontar para uma solicitação servida por HTTPS em vez de carregá-la dentro de si.

Onde você vê isso

O trabalho que os dados de comerciante faziam agora é feito pelo próprio endereço.

Softwares de checkout como o BTCPay Server derivam um endereço novo para cada fatura, então um pagamento que chega identifica seu próprio pedido sem ida e volta e sem estado ecoado. Isso supera o BIP70 em dobro: não há nada para o pagador adulterar, e evita a reutilização de endereços que, de outro modo, publicaria toda a receita de um comerciante para qualquer um que leia a blockchain. As plataformas que guardam seus fundos funcionam do mesmo jeito, e é assim que um depósito cai na sua conta e não na de outra pessoa.

Vale levar uma advertência de tudo isso. Várias outras redes exigem um memo ou uma etiqueta de destino junto a um depósito, e omiti-lo faz com que seus fundos caiam em uma conta coletiva sem nada que os vincule a você. O bitcoin não tem esse campo. Se uma página de depósito pede que você anexe uma etiqueta, um memo ou um código de referência a uma transação de bitcoin, o formulário está mal configurado ou é falso, e recuperar um depósito de fato enviado errado é lento e muitas vezes impossível.

Dados de comerciante do PP vs memo do PP

Os dados de comerciante foram escritos para uma máquina; um memo foi escrito para uma pessoa. Um nunca era mostrado ao cliente, o outro existia apenas para ser mostrado. Seus modos de falha diferem na mesma medida: um memo não verificado engana uma pessoa que lê uma tela de confirmação, enquanto dados de comerciante não verificados enganam o próprio software de contabilidade do comerciante. Nenhum dos dois era assinado na volta, e é por isso que ambos precisavam ser tratados como não confiáveis.