Keysend, MPP y AMP: pagos sin invoice y multipath
No siempre necesitas una invoice. Y a veces un pago necesita viajar por varios caminos a la vez.
Modelo clásico y fricción
El flujo clásico de Lightning es pull: el receptor crea invoice y el pagador la paga. Es sólido, pero en algunos casos es ineficiente, como pagos automáticos de streaming, sistemas machine-to-machine o montos grandes con rutas fragmentadas.
Keysend: pagos espontáneos push
Con Keysend, el emisor puede enviar sats sin invoice previa del receptor. El preimage se transporta en el onion del pago y el receptor cobra al validarlo. Esto habilita flujos continuos como Podcasting 2.0.
El streaming de sats en podcasting usa Keysend para pagar al creador por minuto escuchado sin generar invoices manuales.
MPP: dividir para enrutar mejor
Multi-Path Payments divide un pago en varias partes que viajan por rutas distintas y se recomponen en destino. Permite enviar montos que no caben por una sola ruta de liquidez.
MPP es estándar en implementaciones principales y muchas wallets lo aplican automáticamente para mejorar tasa de éxito.
AMP: variante multipath avanzada
AMP extiende la idea multipath con hashes por fragmento y lógica criptográfica adicional. Tiene más tracción en algunos stacks (especialmente LND), pero menor adopción universal que MPP estándar.
| Tecnología | Invoice requerida | Multipath | Caso típico |
|---|---|---|---|
| Keysend | No | No (base) | Pagos espontáneos y streaming |
| MPP | Sí | Sí | Pagos grandes y robustez de ruta |
| AMP | No | Sí | Push multipath avanzado |