Enrutamiento cebolla

Cada pago Lightning viaja dentro de un paquete de 1.366 bytes de tamaño fijo cuyas capas se pelan de una en una, así que un nodo que reenvía conoce al nodo anterior y al siguiente, nada más. El paquete mantiene el mismo tamaño en cada salto, lo que oculta la longitud de la ruta y el lugar que usted ocupa en ella. Su privacidad frente a los desconocidos del medio es sólida; frente a la billetera o el exchange de cada extremo, no lo es.

Cómo funciona

El enrutamiento cebolla cifra la ruta en capas, una por salto, envueltas en orden inverso para que pelar la capa más externa sea lo único que cualquier nodo pueda hacer.

BOLT 4 llama Sphinx a la construcción, ampliada con una carga útil por salto. Antes de que el pago se mueva, su billetera conoce la clave pública de cada nodo de la ruta y usa ECDH con cada uno para derivar un secreto compartido. De cada secreto compartido salen cuatro claves: rho genera el flujo de bytes que ofusca el paquete, mu calcula el HMAC de integridad, um autentica los errores en el viaje de vuelta y pad inicializa el relleno. Ese flujo es ChaCha20 aplicado sobre ceros con un nonce cero de 96 bits, algo seguro aquí solo porque ninguna clave se reutiliza nunca.

El paquete tiene cuatro campos y un único tamaño fijo: un byte de versión, actualmente 0x00, un punto secp256k1 comprimido de 33 bytes que hace de clave efímera, 1.300 bytes de cargas útiles de los saltos y un HMAC de 32 bytes. Eso suma 1.366 bytes en la red, sin necesidad de prefijo de longitud.

La construcción avanza hacia atrás. La región de 1.300 bytes empieza como bytes aleatorios de un flujo ChaCha20 y, para cada salto desde el último hasta el primero, se desplaza a la derecha para hacer sitio, lo que empuja el extremo más lejano fuera del borde y lo desecha. Para una carga útil de menos de 253 bytes, el desplazamiento es la longitud de esa carga útil más 33: un byte de longitud y 32 bytes de HMAC. Cada desplazamiento va seguido de un XOR con el flujo rho del salto, que vuelve a revolver las capas anteriores.

Lo que lee un salto es una lista corta de campos con tipo: el tipo 2 es amt_to_forward en milisatoshis, el tipo 4 es outgoing_cltv_value, el bloqueo temporal (timelock) que debe poner en el HTLC que ofrezca a continuación, y el tipo 6 es short_channel_id, que nombra el canal que se debe usar, aunque un nodo puede optar por otro canal hacia el mismo par. En lugar de ese ID corto de canal, el nodo final recibe el tipo 8, que lleva un secreto de pago de 32 bytes y el monto total.

Un paso más impide vincular entre sí los paquetes consecutivos. Cada salto aplica un ajuste (tweak) a la clave efímera con un factor de cegado antes de pasarla, así que el mismo paquete cebolla parece bytes sin relación en cada enlace que cruza. BOLT 4 reconoce el límite con franqueza: la ofuscación "does not preclude the possibility of packet association by an attacker via traffic analysis." (No descarta que un atacante asocie los paquetes mediante análisis de tráfico.)

Por qué importa cuando compra bitcoin

El enrutamiento cebolla lo protege de los desconocidos que están en medio de una ruta y de nadie en ninguno de sus extremos, y eso es lo que más se malinterpreta de la privacidad en Lightning.

El primer salto suele ser un servicio con el que usted ya tiene una relación, y ve mucho más que un nodo cualquiera que reenvía. Nuestra reseña de Phoenix cita las propias preguntas frecuentes de ACINQ sin suavizarlas: "The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments." (La versión actual de Phoenix no ofrece ninguna ventaja de privacidad frente a las billeteras alojadas y con custodia existentes, y ACINQ conoce el destino final y el monto de los pagos.) Phoenix tiene aquí una calificación de 4,0 y es realmente de autocustodia: un nodo real en el teléfono, protegido por una frase semilla de 12 palabras. La custodia y la privacidad son cuestiones distintas, y Phoenix solo responde bien a una de ellas.

El extremo que recibe no está mejor. Strike funciona con custodia mientras los fondos permanecen en la aplicación y exige verificación de identidad, así que un retiro Lightning a su propia billetera le dice a Strike el monto, el momento y la factura que pagó, por muchos saltos que haya cruzado el paquete cebolla. Wallet of Satoshi lleva un estado de precaución y una calificación de 2,7 en este sitio, en parte porque la empresa conserva las claves, y ya retiró de la Unión Europea su servicio Lightning con custodia.

Así que no tome el enrutamiento cebolla como una forma de eludir el cumplimiento normativo. No cambia qué sección de legalidad de una guía de país se le aplica, no oculta una compra al exchange que se la vendió y no le aporta nada cuando el operador de su billetera es uno de los endpoints. Lo que sí ofrece sigue valiendo la pena: un nodo de enrutamiento del que usted nunca ha oído hablar no puede construir un grafo de quién paga a quién, no puede saber si usted es el remitente u otro salto y no puede distinguir una ruta corta de una larga.

Pagar una factura de Strike a través de dos nodos de los que nunca ha oído hablar

Pagar una factura de Strike por Lightning muestra qué averigua y qué no averigua cada nodo de una ruta.

Suponga que su billetera elige una ruta de cuatro nodos: su propio par, dos nodos de enrutamiento públicos y luego Strike. El paquete se construye desde Strike hacia atrás. La carga útil de Strike recibe el monto final y el secreto de pago. Cada carga útil intermedia recibe un amt_to_forward que todavía incluye las comisiones de todos los nodos que vienen después, un outgoing_cltv_value rebajado en la delta que anuncia ese nodo y el short_channel_id del enlace que debe usar.

El segundo nodo de enrutamiento lee exactamente una carga útil. Averigua que el nodo anterior le entregó un HTLC y que debe ofrecer uno algo menor hacia adelante. No averigua que Strike está al final, no averigua que usted está al principio y no puede saber si la ruta tiene cuatro saltos u ocho, porque la región que pasa al siguiente son los mismos 1.300 bytes que recibió.

Si ese nodo no tiene liquidez para el reenvío, construye un paquete de retorno: un HMAC calculado con su clave um, un código de fallo, relleno elegido para que el mensaje de fallo más el relleno llegue al menos a 256 bytes, y el resultado combinado mediante XOR con un flujo derivado de una clave ammag. Cada salto lo vuelve a ofuscar en el viaje de vuelta. Su billetera quita las capas y luego sigue descifrando hasta que el bucle se ha ejecutado 27 veces, la ruta más larga que permite el formato de carga útil TLV, para que el nodo que falla no pueda deducir su posición midiendo el tiempo de un intento repetido. Los nodos más nuevos también adjuntan datos de atribución: HMAC truncados a 4 bytes, 210 de ellos para una ruta del tamaño máximo de 20 saltos, y tiempos de retención en unidades de 100 milisegundos.

Enrutamiento cebolla frente a ruta ciega

El enrutamiento cebolla oculta la ruta a los nodos que transportan un pago, mientras que la ruta ciega oculta el tramo final de la ruta a quien paga.

El enrutamiento cebolla simple necesita que el remitente conozca la clave pública real de cada nodo, porque los secretos compartidos salen de ECDH con esas claves. El cegado de rutas invierte eso en el último tramo: el destinatario construye una secuencia de ID de nodo ajustados, que convierte a Bob en Bob prima y a Carol en Carol prima en el propio ejemplo de BOLT 4, y luego entrega al remitente un punto de introducción más un blob cifrado (datos opacos) por salto. El remitente envuelve en una cebolla unos blobs que no puede leer. Los dos se combinan en lugar de competir: BOLT 4 exige que todo mensaje cebolla use el cegado de rutas, y un mensaje cebolla usa el mismo formato de paquete que la cebolla de un pago.

Enrutamiento cebolla frente a HTLC

El enrutamiento cebolla lleva las instrucciones y el HTLC lleva el dinero, y un pago Lightning necesita ambos porque cada uno comprueba al otro.

El paquete cebolla le indica a un salto adónde reenviar y cuánto. El HTLC es el pago condicional que realmente se ofrece en el canal. Como un HMAC de todo el paquete, que solo el remitente y ese salto pueden producir, cubre la región de cargas útiles, un nodo compara el HTLC que le ofrecieron con el amt_to_forward y el outgoing_cltv_value escritos para él, y devuelve el HTLC como fallido cuando no coinciden, lo que delata a un nodo anterior que recorta el monto en silencio. También pueden ir por separado: un mensaje cebolla, de tipo 513, es la misma construcción sin dinero, y ningún salto intermedio devuelve nunca un error por uno de ellos.