Keysend

Keysend invierte el flujo normal de Lightning, en el que el destinatario elige un secreto y publica su hash en una factura. El secreto del remitente viaja en el registro TLV personalizado 5482373484, un número par, que BOLT 1 obliga a un nodo que no conoce keysend a rechazar en lugar de ignorar. Se puede pagar a la clave pública de un nodo, sin nada más y sin viaje de ida y vuelta, y se renuncia al recibo criptográfico que habría dejado una factura.

Cómo funciona

Keysend se apoya en la mitad más estricta de una regla de BOLT 1: un lector descarta un registro TLV desconocido de tipo impar y sigue adelante, pero ante uno par desconocido debe hacer fallar todo el flujo.

Los identificadores de tipo por debajo de 2^16 están reservados para los BOLT y todo lo que va de 2^16 en adelante queda libre para registros personalizados, y BOLT 1 indica elegir un número impar cuando los nodos ordinarios deben ignorar los datos y uno par cuando deben rechazarlos. bLIP-3 deja constancia de que la implementación original de lnd eligió 5482373484 al azar, y ese número termina en cuatro, así que keysend quedó del lado que rechaza. Por eso necesita un bit de funcionalidad: los nodos que lo aceptan anuncian el bit 54/55, llamado keysend, que depende de la funcionalidad var_onion_optin, y bLIP-3 dice que los remitentes deberían buscarlo en lugar de enviar a ciegas y ver cómo falla el pago.

La tarea del remitente, descrita en bLIP-3, es breve. Generar un valor aleatorio de 32 bytes criptográficamente seguro, colocarlo en ese registro y establecer el campo payment_hash del mensaje update_add_htlc como su SHA-256. Nunca reutilizar una preimagen, y nunca reutilizar la de una factura ya pagada. El paquete se ofusca en cada salto, de modo que un salto recupera solo la dirección del siguiente y nadie en medio ve el registro. El nodo final calcula el hash del valor que encuentra, lo compara con el hash que se le pidió aceptar y liquida.

El rechazo es deliberadamente silencioso. BOLT 4 tiene una respuesta literal para una carga útil que un nodo no entendió, PERM|22 invalid_onion_payload, que puede incluso indicar el tipo TLV causante. bLIP-3 pide a los destinatarios que devuelvan en su lugar el código de fallo PERM|15 incorrect_or_unknown_payment_details, de modo que un keysend rechazado no se distingue de un hash de pago que el nodo nunca emitió.

Dónde aparece

Keysend es la infraestructura que sostiene los boosts de pódcast.

bLIP-10 define un segundo registro, de tipo 7629169, elegido originalmente por Breez, que lleva un objeto JSON plano adjunto al pago keysend: el título del pódcast, el episodio, el campo ts para la posición de reproducción en segundos, el campo action con el valor boost o stream, y un campo message opcional, que es lo que da lugar a un boostagram. El streaming por minuto establece el campo seconds_back en 60. Ese registro es impar, y por eso bLIP-10 resta importancia a la compatibilidad con versiones anteriores: un presentador que hace caso omiso de los metadatos se queda igualmente con los sats. Existe porque un keysend por sí solo no le dice nada al destinatario, así que una aplicación tiene que nombrar el programa por su cuenta.

La misma carencia deja a keysend fuera del proceso de compra. Un retiro de un exchange o bien le entrega a usted una factura o bien le pide una, porque la plataforma tiene que vincular el pago con su cuenta, y la palabra no aparece en ninguno de los 63 registros de exchanges ni en ninguna de las 41 reseñas de billeteras de este sitio. bLIP-3 expone la contrapartida con honestidad: espera que keysend dé paso a un pago espontáneo mejor diseñado, menciona las ofertas y AMP, y enumera lo que se pierde mientras tanto, la prueba de pago y cualquier control del beneficiario sobre la expiración CLTV final.

Keysend frente a dirección Lightning

Keysend y una dirección Lightning le permiten a usted pagar a alguien que nunca le entregó una factura, y solo uno de los dos prescinde de verdad de la factura. Escribir user@example.com hace que su billetera realice una consulta HTTPS que devuelve una factura BOLT11 nueva, así que la preimagen sigue siendo elección del destinatario y usted acaba teniendo un recibo respaldado por la firma de este. Keysend no necesita ninguna solicitud web ni ningún servidor, solo la clave pública de 33 bytes del nodo y una ruta hasta él, y después no le deja ninguna forma de probar el pago, porque el secreto fue suyo desde el principio. Si alguna vez pudiera necesitar demostrar que pagó, opte por la factura.