Ruta ciega

El destinatario construye la ruta y la entrega, de modo que el pagador enruta hasta un punto de introducción público y no más allá. Una factura BOLT 12 se rechaza si no lleva ninguna ruta ciega, y los saltos cegados comparten con el resto de la ruta la carga útil fija de 1300 bytes del paquete cebolla. Si usted publica un destino Lightning, el cegado mantiene el ID de su nodo fuera de él.

Cómo funciona

Una ruta ciega se construye hacia atrás, y la construye el nodo que quiere ser alcanzado, no el nodo que paga.

El destinatario parte de una ruta real hasta sí mismo y de una clave efímera aleatoria, a partir de la cual deriva una cadena de claves de ruta dispuestas de modo que cada salto pueda calcular la siguiente sin que nadie se lo diga. Cada salto termina compartiendo un secreto ECDH con el destinatario, y de ese secreto salen dos cosas. La primera es un factor de cegado, el HMAC de la cadena de caracteres blinded_node_id calculado con el secreto compartido, que el destinatario multiplica por la clave pública de ese salto. El salto puede seguir firmando con el resultado, porque deriva el mismo factor y lo aplica a su propia clave privada, pero nadie más puede cotejar esa clave con el grafo publicado. La segunda es una clave de cifrado, que se usa para sellar un pequeño sobre de instrucciones para ese salto con ChaCha20-Poly1305 y un nonce formado solo por ceros.

Lo que se publica es breve: el punto de introducción en claro, una clave de ruta inicial y después una lista de claves ajustadas, cada una emparejada con su sobre sellado. Dentro de un sobre van los campos que lee ese salto: short_channel_id o next_node_id para saber hacia dónde sigue el pago, payment_relay para la comisión y la delta CLTV que debe aplicar, payment_constraints para una expiración máxima y un tamaño mínimo de HTLC, relleno y, en el último salto, un path_id.

Tres de esas decisiones son defensivas más que funcionales. El destinatario, no el pagador, establece la comisión y el bloqueo temporal (timelock) de cada salto cegado, de modo que un nodo intermedio no puede subir su precio a mitad de ruta y observar qué pagos fallan. Rellena todos los sobres hasta una misma longitud y puede añadir saltos ficticios que después descarta, de modo que la longitud real no puede leerse a partir de la forma. Y el path_id contiene datos privados, la preimagen por ejemplo, para que el destinatario pueda confirmar una ruta que construyó él mismo en lugar de aceptar una que un atacante lanzó contra cada nodo del que sospecha.

BOLT 12 añade una última pieza de camuflaje. En lugar de una comisión por cada salto cegado, una factura lleva exactamente un campo blinded_payinfo por ruta: una comisión base en milisatoshis, una comisión proporcional en millonésimas, una única delta CLTV agregada, un tamaño mínimo y máximo de HTLC, y un vector de funcionalidades. La razón declarada es que el detalle por salto revelaría trivialmente una falta de uniformidad que distinguiría la ruta.

Por qué importa cuando compra bitcoin

Las rutas ciegas cambian lo que la parte intermedia de la red Lightning sabe de usted, y no cambian nada de lo que sabe su propio primer salto.

El cegado de rutas oculta los saltos posteriores al punto de introducción, y no dice nada del nodo a través del cual se conecta su billetera, que es el que ve sus montos y destinos. Phoenix, calificada con 4,0 entre nuestras 41 reseñas de billeteras, es inusualmente honesta al respecto: las propias preguntas frecuentes de ACINQ dicen que la billetera no ofrece ninguna ventaja de privacidad frente a una billetera con custodia alojada, y que ACINQ conoce el destino final y el monto de los pagos. Una ruta ciega en una oferta que usted paga no cambia eso.

La custodia elimina la pregunta por completo. Wallet of Satoshi, calificada con 2,7 en este sitio y marcada con una advertencia, guarda las claves en su modo con custodia, así que los dos extremos de un pago son registros de la propia empresa; dejó de atender a los clientes de Estados Unidos el 23 de noviembre de 2023 y desde entonces ha retirado el servicio con custodia en toda la Unión Europea. Nada suyo se cega cuando el pago nunca sale de los libros contables del proveedor.

Donde el cegado sí le aportaría algo es en el propio retiro. Strike, la plataforma centrada en Lightning mejor calificada de este sitio, con 4,6, no añade ninguna comisión propia a las transferencias y paga a un destino Lightning que usted indique. Si le entrega una factura BOLT 11, le entrega también su nodo: la firma lleva un ID de recuperación, así que la clave del beneficiario puede recuperarse a partir de ella. Una oferta pone ahí, en su lugar, un punto de introducción, siempre que el pagador admita una.

El costo está en el diagnóstico. Los saltos dentro de una ruta ciega devuelven fallos sin datos de atribución, y al punto de introducción se le indica que añada un retraso aleatorio antes de reenviar un error, de modo que el sondeo no puede medir a qué distancia está el destinatario. Por eso, un retiro que falla hacia un destino cegado apenas le dice nada, así que pruébelo desde una billetera que usted controle antes de culpar a la plataforma.

Dave entrega a Alice una ruta a través de Bob y Carol

La especificación de Lightning desarrolla la idea de la ruta ciega con cuatro nombres, algo más rápido de seguir que el álgebra.

Dave quiere cobrar sin que Alice sepa que es él. Elige una ruta hacia sí mismo a través de dos nodos públicos, primero Bob y después Carol, y construye la cadena de claves de ruta para que los tres deriven la suya. Después sella tres sobres: uno que indica a Bob que reenvíe a Carol, otro que indica a Carol que le reenvíe a él y otro para sí mismo con metadatos y el path_id. Por último, deriva los factores que convierten a Bob en Bob prima, a Carol en Carol prima y a Dave en Dave prima.

Alice recibe tres líneas: el primer nodo es Bob, esta es la primera clave de ruta, y esta es la secuencia Bob prima, Carol prima, Dave prima, con un sobre sellado junto a cada uno. Llega a Bob por el grafo público ordinario, y es deliberado: la especificación recomienda un tramo sin cegar hasta el punto de introducción, porque no requiere que los nodos intermedios lo admitan y devuelve errores que se pueden leer. Bob desella su instrucción, solo sabe que Carol es la siguiente y reenvía la clave de ruta derivada junto con el paquete cebolla. Carol usa esa clave dos veces: una para ajustar el paquete cebolla, que Alice cifró para Carol prima y no para Carol, y otra para desellar su propia instrucción. Dave lo recibe en último lugar y comprueba el path_id antes de aceptar.

Cuente lo que cada uno termina sabiendo. Alice conoce a Bob. Bob sabe que es un punto de introducción y que Carol es la siguiente. Carol sabe que un pago cegado pasó por ella y no puede distinguir si Dave es el destinatario u otro nodo intermedio. Dave lo sabe todo, porque es el único que la construyó.

Ruta ciega frente a route hint

Una ruta ciega y un route hint (pista de ruta) responden a la misma pregunta, cómo llegar a un nodo que el grafo público no puede ver, y revelan cantidades opuestas al hacerlo.

Un route hint es el campo r de una factura BOLT 11, y es texto plano. Cada elemento lleva una clave pública de 264 bits, un ID corto de canal de 64 bits, una comisión base, una comisión proporcional y una delta CLTV, todo en claro, así que cualquiera que tenga la factura sabe de qué nodo bien conectado depende usted. Una ruta ciega nombra el punto de introducción y después se vuelve opaca: cada salto posterior es una clave ajustada que no coincide con nada del grafo, y las comisiones llegan agregadas en lugar de desglosadas. Las rutas ciegas también asumen una tarea que los route hints nunca tuvieron: hacen las veces de los campos payment_secret y payment_metadata de una factura BOLT 11.

Ruta ciega frente a enrutamiento cebolla

El enrutamiento cebolla oculta al pagador frente a los saltos; una ruta ciega oculta al beneficiario frente al pagador.

En el enrutamiento cebolla simple, el remitente elige cada salto del grafo público y envuelve una capa de cifrado por salto, de modo que ningún nodo que reenvía sabe quién paga ni en qué punto de la ruta se encuentra. El remitente sigue conociendo la ruta completa, incluido el ID de nodo real del destino, lo que está bien para pagar a una tienda y es inútil para publicar un destino reutilizable. El cegado de rutas aporta la mitad que faltaba sin reemplazar nada: un pago a través de una ruta ciega sigue siendo un paquete cebolla, y el cegado es un ajuste (tweak) de clave superpuesto. Son lo bastante separables como para que un destinatario que no quiera la privacidad pueda construir una ruta de un solo salto que solo lo contenga a él y revelar de todos modos el ID de su nodo.