Hash de pago

Cada salto de una ruta Lightning ve el mismo hash de pago, que es lo que identifica el pago ante cada uno de ellos. BOLT 11 exige exactamente uno por factura, escrito como 52 caracteres bech32 que llevan 256 bits. Mostrar el secreto correspondiente es la única forma de reclamar el dinero, y conservar ese secreto después es su recibo.

Cómo funciona

Un hash de pago empieza su vida como su opuesto: el destinatario elige 32 bytes aleatorios, llamados preimagen del pago, y publica solo su SHA-256.

Ese valor entra en la factura con la etiqueta p, que BOLT 11 establece en un data_length de 52 y exige exactamente una vez. Desde ahí recorre la ruta dentro de update_add_htlc, el mensaje de tipo 128, cuyos campos son el ID de canal, un contador de 64 bits, el monto en milisatoshis, el propio payment_hash, una expiración CLTV y un paquete cebolla de 1366 bytes. En ese mensaje cumple una doble función: también se entrega a la construcción del paquete cebolla como datos asociados, de modo que los HMAC de cada salto lo cubren. Por eso, repetir un paquete cebolla antiguo con un hash de pago distinto falla en el primer nodo que lo comprueba.

La liquidación recorre el hash en sentido inverso. El destinatario devuelve la preimagen en update_fulfill_htlc, el mensaje de tipo 130, como un simple valor de 32 bytes, y cada nodo anterior en la ruta la devuelve por los mismos canales. Un nodo que recibe una preimagen cuyo SHA-256 no coincide con el hash que tiene retenido no se limita a hacer caso omiso de ella: BOLT 2 dice que debe enviar una advertencia y cerrar la conexión, o bien enviar un error y hacer fallar el canal, porque no hay ninguna explicación inocente.

On-chain, el hash se recorta. El script de bloqueo de la salida HTLC no contiene en absoluto el valor de 32 bytes; ejecuta una comparación OP_HASH160 con RIPEMD160(payment_hash), un compromiso de 20 bytes, y quien gasta aporta la preimagen en el testigo. Dos HTLC ofrecidos con el mismo monto redondeado y el mismo hash de pago producen salidas idénticas byte a byte aunque sus expiraciones difieran, y por eso BOLT 3 tiene que especificar una regla para ordenarlas.

Un requisito parece extraño hasta que se ve el ataque que hay detrás. Un nodo debe aceptar varios HTLC que lleven el mismo hash de pago, y BOLT 2 explica el motivo: si se rechazaran los duplicados, un atacante podría sondear con un hash conocido y averiguar si ese nodo ya tenía retenido ese pago. El ID independiente de 64 bits existe para distinguir los duplicados.

Por qué importa cuando compra bitcoin

Dos de los 63 exchanges reseñados en este sitio documentan un pago por Lightning en sus notas de comisiones: Strike, cuya nota de retiros dice que se admiten retiros a billeteras por Lightning y on-chain, y Coinbase, cuya tabla de comisiones pone a un envío Lightning un precio del 0,2 % del monto enviado.

Cuando uno de esos pagos se estanca, no hay ningún ID de transacción que consultar, porque nada llegó a la blockchain. El hash de pago es la única cadena de caracteres que tienen a la vez el registro de su billetera y el departamento de operaciones del exchange, así que cópielo de la pantalla de detalle del pago antes de cerrarla. Un servicio de soporte que le pide "el ID de transacción" de un retiro Lightning le está pidiendo este valor.

El error que recibe no le dirá mucho, y es a propósito. BOLT 4 agrupa cinco problemas distintos en un solo código de fallo, incorrect_or_unknown_payment_details, numerado PERM|15: el nodo final no conoce el hash, el secreto de pago no coincide con él, el monto para ese hash es demasiado bajo, la expiración queda demasiado cerca de la altura de bloque actual o faltan metadatos de pago obligatorios. La especificación explica por qué los agrupó. Los antiguos códigos separados permitían a un nodo que reenvía adivinar adónde iba un pago reenviando el mismo hash con un valor mucho menor y leyendo la respuesta. Su billetera no le está ocultando el motivo: a ella nunca se lo comunicaron, así que volver a generar la factura y pagar de nuevo es la respuesta práctica.

El mismo valor se mantiene idéntico desde su nodo hasta el del destinatario, incluso en todas las partes de un pago multiparte, que según BOLT 4 deben compartir un único hash de pago. Quien lo ve dos veces sabe que está ante un solo pago. Nuestra reseña de Phoenix cita las propias preguntas frecuentes de ACINQ, donde admite que conoce el destino final y el monto de los pagos hechos con la billetera, lo que es la versión sin rodeos de la misma exposición, declarada por el proveedor y no deducida en este sitio.

Reutilizar una factura es peor que inútil por una razón relacionada. BOLT 4 deja a un nodo final al que se le entrega un hash ya pagado libertad para tratarlo como desconocido o para aceptar el dinero, así que el resultado de un código QR publicado de nuevo depende de la implementación que, por casualidad, use el destinatario.

Decodificar el hash de pago del vector de prueba de donación de BOLT 11

La especificación BOLT 11 incluye un ejemplo práctico de factura de donación, y el hash de pago que contiene es un valor de prueba fijo que ninguna billetera debería producir nunca.

El ejemplo lleva como título "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102" y el código empieza por lnbc1pvjluez. Tras el prefijo lnbc y el separador bech32, pvjluez es la marca de tiempo, 1496314658 segundos desde el inicio de 1970. Después viene el campo del secreto de pago, y tras él la etiqueta p y luego p5, que es la longitud: en bech32, p vale 1 y 5 vale 20, así que el campo ocupa 1 * 32 + 20 = 52 caracteres. Esos caracteres, qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, se decodifican en el hash citado en ese título.

Nada de esto es privado. La especificación publica la clave privada con la que se firman sus ejemplos, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, y dice que todas las facturas de esa sección llevan el secreto de pago 1111111111111111111111111111111111111111111111111111111111111111 salvo que indique lo contrario, así que estos códigos son datos de prueba para analizadores y no solicitudes de pago. Si una billetera o una herramienta de diagnóstico le muestra alguna vez ese hash fuera de un conjunto de pruebas, algo está copiando la especificación en lugar de informar de su pago.

Hash de pago frente a ID de transacción

Un hash de pago nombra un pago Lightning; un ID de transacción nombra una transacción que existe en la blockchain de bitcoin. Ambos ocupan 32 bytes y ambos se muestran como 64 caracteres hexadecimales, y así es como cada uno acaba en los formularios de soporte del otro. Un ID de transacción se calcula a posteriori a partir de los propios bytes de la transacción y puede pegarse en cualquier explorador de bloques. Un hash de pago lo elige el destinatario antes de que exista el pago, nunca aparece en un bloque cuando el pago se liquida con normalidad y no devuelve nada en un explorador. Un resultado de búsqueda vacío suele significar que usted tiene el valor correcto y la herramienta equivocada.

Hash de pago frente a secreto de pago

Un hash de pago y un secreto de pago son dos valores distintos de 256 bits de la misma factura, transportados en las etiquetas p y s y codificados cada uno como 52 caracteres bech32. El hash es necesariamente público: cada salto tiene que verlo para construir su HTLC. El secreto se entrega solo al último nodo, dentro del paquete cebolla, y BOLT 11 resume su función en una línea: "prevents forwarding nodes from probing the payment recipient" (impide que los nodos que reenvían sondeen al destinatario del pago). Quien lee la factura y no encuentra ningún campo s debe hacer fallar el pago de inmediato. El hash es el bloqueo; el secreto es una prueba de que quien paga obtuvo la factura de la persona que la emitió.