PaymentRequest

PaymentRequest era el mensaje que permitía a una billetera mostrar el nombre de una empresa en lugar de una cadena de caracteres. Tenía cinco campos, y los dos que importaban eran pki_type, con uno de los valores none, x509+sha256 o x509+sha1, y signature, la firma sobre los detalles serializados. Para quien paga hoy, la lección sobrevive al protocolo: un nombre en una pantalla de pago solo es tan fiable como quien lo avaló.

Cómo funciona

Estado: obsoleto. Bitcoin Core incluyó el manejo de PaymentRequest desde la 0.9.0 hasta que la 0.20.0 lo eliminó el 3 de junio de 2020, y hoy ninguna billetera con mantenimiento activo interpreta el mensaje.

Cinco campos, en orden:

• payment_details_version, un entero de 32 bits con valor predeterminado 1. Nunca se incrementó.
• pki_type, una cadena de caracteres con valor predeterminado "none". Las alternativas eran "x509+sha256" y "x509+sha1".
• pki_data, que contenía una estructura X509Certificates con el certificado de hoja del comerciante en primer lugar y los certificados intermedios, si los había, detrás.
• serialized_payment_details, obligatorio, la cadena de bytes opaca que se describe en otra entrada de este glosario.
• signature, los bytes que demuestran que todo procede del titular del certificado.

El procedimiento de firma tiene un pequeño truco. El comerciante rellena todos los campos, deja signature vacío, serializa el mensaje completo, calcula su hash, firma ese hash con la clave privada que corresponde al certificado de hoja y después escribe la firma en el campo que acababa de dejar en blanco. Un verificador vacía de nuevo el campo, vuelve a serializar y verifica. Sencillo, autónomo y sin depender de nada salvo del certificado.

Esa dependencia era el problema. Validar la cadena de certificados exigía que la billetera tuviera un almacén de certificados raíz, que el software de escritorio tomaba del sistema operativo y que el software móvil a menudo gestionaba mal. Incluso una implementación correcta solo demostraba que alguna autoridad de certificación había dado fe de un nombre de dominio, y un almacén de certificados raíz contiene cientos de autoridades, cualquiera de las cuales puede emitir certificados para cualquier nombre. La opción más débil disponible, x509+sha1, envejeció especialmente mal: el 23 de febrero de 2017, cuatro años después de que se redactara el BIP70, se publicó una colisión práctica de SHA-1.

Dónde aparece

Hay dos lugares donde aún se usa el nombre PaymentRequest, y solo uno de ellos tiene que ver con bitcoin.

El primero es el código y la documentación archivados, donde el tipo MIME del BIP71 application/bitcoin-paymentrequest marcaba la respuesta que devolvía el servidor de un comerciante. El segundo es la plataforma web moderna, donde PaymentRequest nombra una API del navegador para pagos con tarjeta y con métodos de pago guardados que no tiene nada que ver con este protocolo. Un desarrollador que usa la palabra hoy casi con seguridad se refiere a la del navegador, y confundir las dos es el error más común al buscar documentación antigua de bitcoin.

Para quien compra bitcoin, la conclusión tiene que ver con cómo se asocia la identidad a los pagos. Los exchanges lo resuelven con cuentas y KYC (conozca a su cliente), de modo que la plataforma sabe quién es usted y usted confía en la reputación de la plataforma. La autocustodia lo resuelve haciendo que usted mismo compruebe la dirección. El BIP70 probó una tercera ruta, tomar prestado el sistema de certificados de la web, y esa ruta está cerrada.

PaymentRequest frente a PaymentDetails

PaymentRequest es el sobre; PaymentDetails es la carta que va dentro. Leer el sobre indica quién firmó y qué certificado usó, pero no qué se pide. Los montos, los scripts, la expiración y el memo están todos en el mensaje interno, que va en el sobre como una cadena de bytes sin interpretar precisamente para que ninguna nueva codificación pueda invalidar la firma. Una billetera tenía que verificar el primero antes de confiar en nada del segundo.