-
Una tarifa baja puede evitar que una transacción de compromiso se confirme antes a tiempo.
-
Los desarrolladores reevalúan la propuesta de canales de anclaje para combatir el problema.
La red de canales de pago en Bitcoin, Lightning Network (LN), ha estado en desarrollo durante varios años y como parte de ello, se siguen encontrando ciertas debilidades que exponen la seguridad de sus usuarios y sus fondos. Una reciente discusión entre desarrolladores alerta sobre una nueva vulnerabilidad que le permitiría a un atacante robar fondos aprovechando la función “reemplazo por comisión” (RBF), con la cual es posible sustituir una transacción no confirmada por una versión diferente con una tarifa más elevada.
Los canales de anclaje que se encuentran en fase experimental, es un mecanismo de seguridad para confirmar transacciones de compromiso. Cada vez que el saldo cambia en un canal LN, los participantes crean y firman una transacción de compromiso. La transacción solo se transmite si una de las partes decide cerrar el canal unilateralmente —por ejemplo, porque la otra parte no responde—.
Debido a que la transmisión de la transacción por compromiso puede ocurrir mucho tiempo después de su creación, los usuarios pueden pagar demasiado o muy poco en tarifas de transacción. Pagar una tarifa demasiado baja puede evitar que la transacción de compromiso se confirme antes de que caduquen los bloqueos de tiempo contenidos en ella, lo que permite el robo de fondos.
El desarrollador Jimmy Song, publicó un artículo el 27 de abril, en el cual comenta sobre la importancia de defenderse de todos los ataques posibles. Entre las vulnerabilidades que están consumiendo las neuronas de los desarrolladores, Song destaca la de Lightning y RBF Pinning que ya ha exigido una extensa discusión en la lista de correo de desarrolladores de bitcoin.
«Esencialmente, es poco probable que se explote la vulnerabilidad a través del Reemplazo por comisión que permite a cualquiera de las partes usar «El Niño Paga por el Padre» (CPFP). El «RBF carveout», o la transacción CPFP, puede ser usada en conjunto con un minero para potencialmente robar algunos fondos», agrega el desarrollador, quien también señala que cuando se trata de seguridad nada puede parecer paranoico, porque quien ha trabajado con la seguridad sabe que todos estamos a una vulnerabilidad de que ocurran cosas realmente malas.
¿Cómo sucede el ataque?
En su publicación, Song expone una serie de mejoras en las que trabajan los desarrolladores con el objetivo de mejorar aún más el sistema. Para comprender mejor en qué consiste la vulnerabilidad Lightning – RBF Pinning, CriptoNoticias consultó la opinión de un experto, se trata del desarrollador Sergi Delgado, quien explicó: “Supongamos un escenario de Lightning Network con 3 nodos: A, B, y C, y un contrato de tiempo de hash bloqueado (HTLC), el cual ha sido ofrecido por A a C a través de B”.
Un contrato de tiempo de hash bloqueado o HTLC es un método de pago que bloquea los fondos a la espera que el receptor reconozca haber recibido la transferencia antes de la fecha límite. El concepto es bastante simple y sirve como una forma de extender los canales de pago más allá de un estado bidireccional.
Todo comienza de manera normal cuando Alice — el remitente— decide enviar un pago a Carlos —beneficiario— a través de Bob —intermediario—. Para evitar que sus fondos se vean comprometidos, Alice asegura su transacción utilizando un contrato HTLC. Carlos, con mala intención entre manos, gastaría el pago HTLC utilizando la preimagen; creando una nueva versión de la transacción (RBF) con baja comisión, pero lo suficientemente alta como para que entre en la mempool sin que sea confirmada. Bob, no se da cuenta que el HTLC ya ha sido gastado, por lo que intentará reclamarlo cuando este expire, pero su transacción no será aceptada porque se encuentra en conflicto con la nueva versión que Carlos introdujo previamente.
Debido a que los nodos LN no monitorizan la mempool, Bob no se entera de que su transacción está en conflicto con la transacción enviada por Carlos, por lo que no podrá utilizar la preimagen para invalidarla. Después de unos bloques, Alice podrá reclamar su HTLC por expiración, haciendo que Bob pierda el dinero ofrecido por ese pago.
Monitorizar la mempool no tiene por qué ayudar a solucionar el problema. A diferencia de la blockchain, la mempool no está consensuada por los nodos de la red, lo que hace que pueda haber diferentes versiones de una misma transacción. Esto hace que el atacante pueda enviar versiones diferentes de las transacciones a la mempool del nodo atacado, y al resto de la red, haciendo que la solución no sea efectiva.
Sergi Delgado, desarrollador.
El desarrollador agrega que la vulnerabilidad de Lightning Network tiene su origen en la nueva propuesta de canales de anclaje, ya que permite reemplazar una transacción por comisión, lo cual posibilita que las transacciones no confirmadas permanezcan más tiempo en la mempool.
“Esto hace que, por ejemplo, un nodo malicioso pueda añadir una segunda transacción gastando de la primera, asegurándose de que esta no será confirmada —de nuevo dado que la segunda transacción tiene fees aceptables, pero el paquete de la transacción A + B, no las tiene—, además que reemplazar estas transacciones para evitar el ataque, puede costar más que el valor que se gana con ellas”, explicó Delgado.
No es una falla fácil de explotar
Sergi Delgado coincide con Jimmy Song cuando comenta que este tipo de ataques es poco probable, pero también está de acuerdo en que ello no significa que hay que bajar la guardia. «Con el estado actual de LN, la probabilidad de que se explote esta vulnerabilidad es baja, porque implicaría hacer una predicción muy exacta de las comisiones de la transacción para conseguir que esta sea propagada, pero no confirmada y tampoco eliminada de la mempool por tener tarifas muy bajas», apunta.
Con respecto a las soluciones que se están planteando para mitigar la vulnerabilidad, Delgado agrega: «Respecto al modelo actual, no hay ninguna solución fácil de aplicar, de lo contrario ya se habría aplicado anteriormente. Con respecto a anchor outputs, se está considerando reestudiar la propuesta para intentar prevenir este tipo de ataques».
También es conveniente tener presente que Lightning Network tiene otra vulnerabilidad, la cual está vinculada a ataques de sobrecarga de transacciones o congestión de canales. En marzo, CriptoNoticias informó que dos investigadores de la Universidad de Jerusalén publicaron un reporte sobre la capacidad que tienen estos ataques de detener el funcionamiento de ambas redes.