PP merchant data

Asociar un pago a un pedido es el problema poco vistoso que toda página de pago tiene que resolver, y bitcoin lo complica porque una transacción no lleva número de factura. BIP70 lo resolvía entregando a la billetera del cliente una cookie y solicitando que se la devolviera. Hoy los comerciantes resuelven el mismo problema con una dirección de un solo uso por pedido, lo cual es a la vez más sencillo y más privado.

Cómo funciona

Estado: histórico. Los datos del comerciante ocupaban el campo 7 del mensaje PaymentDetails y el campo 1 del mensaje Payment que volvía, y desaparecieron con el resto de BIP70 cuando se publicó Bitcoin Core 0.20.0, el 3 de junio de 2020.

La opacidad era precisamente el objetivo. A la billetera se le indicaba que tratara esos bytes como carentes de significado y los devolviera sin alterar, lo que permitía a cada comerciante inventar su propio esquema sin que nadie más tuviera que entenderlo.

Había dos esquemas habituales. Una clave de búsqueda corta, por ejemplo un identificador de pedido de 16 bytes, mantenía pequeña la solicitud y trasladaba el trabajo a la base de datos del comerciante. Una cadena de bytes autocontenida guardaba el carrito completo y permitía que el servidor funcionara sin estado, a costa del tamaño.

El segundo esquema tiene un agujero sobre el que ya advertía la especificación. Esos bytes vuelven desde un software que el comerciante no controla, así que todo lo que se lea de ellos son datos aportados por un atacante. Una tienda que guardara ahí un precio o un código de descuento y se fiara de la copia devuelta se había construido un generador de cupones. El remedio es el habitual para el estado que hace un viaje de ida y vuelta: adjuntar un código de autenticación de mensajes y comprobarlo antes de leer un solo campo.

El tamaño importaba más de lo que parece. Toda la solicitud firmada tenía que llegar al cliente, y representarla como código QR impone un techo estricto: el símbolo más grande, la versión 40 con el nivel de corrección de errores más bajo, contiene 2.953 bytes de datos binarios. Ese techo es la razón por la que BIP72 definió el parámetro r=, para que un enlace corto pudiera apuntar a una solicitud servida por HTTPS en lugar de llevarla dentro.

Dónde aparece

El trabajo que antes hacían los datos del comerciante ahora lo hace la propia dirección.

Un software de cobro como BTCPay Server deriva una dirección nueva para cada factura, así que un pago entrante identifica su propio pedido sin ida y vuelta y sin estado devuelto. Eso supera a BIP70 por partida doble: no hay nada que el pagador pueda manipular, y evita la reutilización de direcciones que, de otro modo, publicaría todos los ingresos de un comerciante ante cualquiera que lea la cadena. Las plataformas con custodia funcionan igual, y así es como un depósito llega a su cuenta y no a la de otra persona.

De todo esto conviene quedarse con una advertencia. Varias otras redes exigen un memo o una etiqueta de destino junto a un depósito, y omitirlo deja sus fondos en una cuenta colectiva sin nada que los vincule con usted. Bitcoin no tiene ningún campo así. Si una página de depósito le solicita que adjunte una etiqueta, un memo o un código de referencia a una transacción de bitcoin, el formulario está mal configurado o es falso, y recuperar un depósito que de verdad se envió mal es lento y con frecuencia imposible.

PP merchant data frente a PP memo

Los datos del comerciante se escribían para una máquina; un memo se escribía para una persona. Los primeros nunca se mostraban al cliente; el segundo existía solo para mostrarse. Sus modos de fallo difieren en consecuencia: un memo sin comprobar engaña a una persona que lee una pantalla de confirmación, mientras que unos datos del comerciante sin comprobar engañan al propio software contable del comerciante. Ninguno de los dos iba firmado en el viaje de vuelta, y por eso ambos debían tratarse como no fiables.