PP amount

Los errores de pago nacen de las unidades. El monto de BIP70 era un número de satoshis de 64 bits, mientras que el parámetro amount de un URI BIP21 es un valor decimal en bitcoin, así que un mismo pago se escribe 250000 en el primero y 0.0025 en el segundo. Quien mueva dinero entre sistemas debería comprobar qué unidad espera un campo antes de fiarse de un total.

Cómo funciona

Estado: histórico. El campo pertenecía a BIP70, que Bitcoin Core marcó como obsoleto en la 0.19 y eliminó en la 0.20.0 el 3 de junio de 2020.

Dos campos formaban un mensaje Output dentro de un mensaje PaymentDetails: un script que indicaba adónde va el dinero y un monto que indicaba cuánto. El monto era un entero sin signo de 64 bits en satoshis, con cero como valor predeterminado, y el cero tenía un significado concreto. No significaba no pagar nada. Significaba que el comerciante se abstenía de indicar una cifra y que la billetera debía preguntar al cliente, que es como funcionaban las páginas de donaciones.

En una misma solicitud podían aparecer varias salidas, cada una con su propio monto, y la billetera que pagaba tenía que pagarlas todas en una sola transacción. Eso es más útil de lo que parece. Un comerciante podía enviar parte de una venta directamente a almacenamiento en frío, parte a una billetera caliente para reembolsos y parte a un afiliado, todo ello sin que el cliente enviara tres pagos ni supiera que existía el reparto.

El rango nunca fue una limitación. Un entero sin signo de 64 bits llega como máximo a 18.446.744.073.709.551.615 satoshis, aproximadamente 8.800 veces los 2.100.000.000.000.000 satoshis que llegarán a existir. La frontera interesante estaba en el otro extremo. Un monto por debajo del límite de polvo producía una salida que la red no retransmitiría, y la política de Bitcoin Core sitúa ese límite en 546 satoshis para una salida heredada (legacy) pay-to-public-key-hash y en 294 para una salida SegWit de una sola clave.

Dónde aparece

Hoy nada implementa el campo amount de BIP70, pero la confusión de unidades que hay detrás sigue plenamente viva.

Tres especificaciones, tres unidades. Los URI BIP21 expresan los montos en bitcoin. BIP70 los expresaba en satoshis. Las facturas BOLT11 de Lightning afinan todavía más y los expresan en milisatoshis, la milésima parte de un satoshi. Las interfaces de las billeteras añaden además una opción de visualización, así que el mismo saldo aparece como 0,00250000 o como 250.000 según una preferencia que usted configuró una vez y olvidó.

El costo práctico de equivocarse aquí se paga en dinero real. Las estimaciones de comisión llegan en satoshis por byte virtual, así que un gasto SegWit de una entrada y dos salidas, de unos 141 vbytes, cuesta 705 satoshis a 5 sat/vB. Si leyera esa cifra como bitcoin, pensaría que una transacción rutinaria cuesta más de lo que la mayoría de la gente gasta jamás en comisiones en un año.

Dos hábitos lo resuelven. Elija una unidad en la configuración de su billetera y déjela ahí, para que el número de dígitos que espera no cambie nunca. Y lea la etiqueta de la unidad en cualquier pantalla de retiro antes de leer el número, porque los mínimos del exchange, las comisiones de red y su saldo se expresan con frecuencia en unidades distintas en la misma página.

PP amount frente a monto del URI de Bitcoin

Un monto de BIP70 era un entero en satoshis; un monto de BIP21 es un decimal en bitcoin, y el factor entre ambos es 100.000.000. Esa es toda la diferencia, y basta para tener consecuencias. Un campo que contiene 0.0025 en un formato contiene 250000 en el otro, y el software que pasa de uno a otro sin convertir produce un error de ocho órdenes de magnitud en el sentido hacia el que se incline. El formato moderno ganó, así que el número que usted encuentra hoy en un enlace de pago está en bitcoin, salvo que algo indique explícitamente sats.