Secreto de pago

El secreto de pago de Lightning funciona como una contraseña por factura que el pagador repite antes de que el nodo destinatario acepte el dinero. BOLT 11 le asigna la letra de etiqueta s, establece su longitud en 52 caracteres bech32 e indica a quien lee las facturas que haga fallar toda factura que llegue sin él. Para usted, es la razón por la que un nodo de enrutamiento que vio su hash de pago no puede saber que el pago terminó en su billetera.

Cómo funciona

Un secreto de pago lo crea la billetera del destinatario, nunca el pagador, y permanece sellado dentro del paquete cebolla hasta que el pago llega a su último salto.

BOLT 11 lo define como el campo etiquetado de tipo 16, escrito con la letra s y un data_length fijo de 52. Esos 52 caracteres bech32 llevan 260 bits, un valor de 32 bytes más relleno, y quien escribe una factura debe incluir exactamente uno. Quien la lee debe hacer fallar el pago si un campo de longitud fija tiene una longitud incorrecta, y también si no hay ningún campo s válido.

El pagador copia el valor en la carga útil cebolla del último nodo, en lo que BOLT 4 llama registro TLV de tipo 8, payment_data, que contiene el secreto de 32 bytes y una cifra total_msat. Solo el destino puede quitar esa capa, así que los saltos intermedios nunca lo ven, a diferencia del hash de pago en el que todos bloquean sus HTLC.

La comprobación en el destino es deliberadamente poco informativa. Un secreto que no coincide con el esperado para ese hash de pago, o que es obligatorio y falta, hace fallar el HTLC con incorrect_or_unknown_payment_details, el error PERM|15, la misma respuesta que recibe un hash de pago desconocido. BOLT 4 explica por qué se unificaron los errores: los dos códigos anteriores, PERM|16 incorrect_payment_amount y 17 final_expiry_too_soon, permitían a un nodo que reenvía volver a enviar pagos con el mismo hash con valores mucho menores y leer la respuesta para confirmar que había encontrado el destino.

La compatibilidad ya no se negocia. BOLT 9 recoge los bits de funcionalidad 14 y 15, payment_secret, como ASSUMED (supuesto), y los bits 16 y 17, basic_mpp, dependen de esa funcionalidad.

Dónde aparece

Un secreto de pago se reconoce en una cadena de caracteres lnbc moderna como el tramo que empieza por sp5 y continúa durante 52 caracteres de bech32.

En los vectores de prueba de BOLT 11, ese tramo es zyg3 repetido doce veces y luego zygs, y codifica un secreto cuyos 32 bytes valen todos 0x11. Usted nunca teclea un secreto de pago: solo quien escribe la factura y la billetera que paga manejan alguna vez el valor.

Donde el campo demuestra su utilidad es en los pagos multiparte. Cuando ninguna ruta tiene por sí sola liquidez suficiente y la factura ofrece basic_mpp, BOLT 4 permite a una billetera repartir el monto entre varios HTLC que comparten un mismo hash de pago, y cada parte debe llevar el secreto y debería coincidir en total_msat. El destinatario no liquida nada hasta que llega el total, y debería esperar al menos 60 segundos tras el primer HTLC antes de hacer fallar el conjunto con un mpp_timeout. Así, un retiro Lightning más grande desde una aplicación centrada en Lightning como Strike que queda pendiente durante un minuto y luego se devuelve puede ser un conjunto de HTLC incompleto que expira, y no dinero perdido. Tanto si es su propia billetera la que reúne esas partes, como hace Phoenix al ejecutar un nodo Lightning real en el teléfono, como si lo hace un custodio en un servidor que usted no controla, el secreto las marca como un solo pago.

Secreto de pago frente a hash de pago

El hash de pago y el secreto de pago son ambos campos de 256 bits de una misma factura BOLT 11, y la diferencia está en quién llega a verlos. Cada salto conoce el hash, porque cada uno bloquea en él el HTLC que reenvía, mientras que nadie salvo el nodo final conoce el secreto, que viaja en la capa más interna del paquete cebolla. El hash responde a si el pago se liquidó, y la preimagen que lo abre es el recibo. El secreto responde a si el pagador trabaja a partir de la factura que usted escribió, algo que un hash no puede hacer, al ser visible para todos los de la ruta. En la codificación parecen gemelos: etiqueta p y etiqueta s, ambos de 52 caracteres, ambos rechazados con cualquier otra longitud.