Hechos clave:
-
Si exchanges entregan a firmas de anĆ”lisis las descripciones se comprometerĆa la privacidad.
-
Un desarrollador llama a eliminar por completo la descripciĆ³n de pagos en la red Lightning.
Tras el amplio revuelo de los monederos de Bitcoin (BTC) que se plegaron a la Ā«regla de viajeĀ» para cumplir con las regulaciones suizas y neerlandesas, un desarrollador advirtiĆ³ que algo igual pudiera gestarse en la red Lightning (LN, por sus siglas en inglĆ©s), la soluciĆ³n para micropagos de la criptomoneda.
En una publicaciĆ³n en el blog de la FundaciĆ³n Linux, el desarrollador Ā«ArmdxxiĀ» dijo que cuando un nodo de Lightning crea una factura con el formato BOLT11, que incluye una descripciĆ³n de para quĆ© es el pago, Ć©sta es firmada por el emisor con informaciĆ³n detallada. El proceso de verificaciĆ³n de firmas valida que provenga de un nodo especĆfico y que estĆ© inalterado.
Pero ahĆ viene el detalle. Esa descripciĆ³n podrĆa ser Ā«explotadaĀ» por Ā«malos actoresĀ» dentro del espacio regulado. Y los usuarios, incautos, estĆ”n aceptĆ”ndolo sin siquiera conocer las repercusiones.
Una factura BOLT11 es el mecanismo mĆ”s usado en la soluciĆ³n de segunda capa de Bitcoin. En Ć©l, el receptor de los fondos genera un cĆ³digo QR con la factura de pago, la cual permite aƱadir una descripciĆ³n que, en este caso, es el problema.
ĀæCĆ³mo funciona?
Hay formas con las cuales, a travĆ©s de LN, se puede generar un proceso similar al del protocolo AOPP. Con Ć©l, los usuarios de monederos de Bitcoin deben firmar un mensaje desde una direcciĆ³n para demostrar que es suya, en el momento que hacen retiros de mĆ”s de USD 1.000 desde exchanges de criptomonedas centralizados.
La verificaciĆ³n de los nodos conoce-tu-cliente (KYC, por sus siglas en inglĆ©s) es uno de esos procesos. AcĆ”, se puede crear una Ā«factura especializadaĀ» para verificar esos puntos.
Esa Ā«facturaĀ», que incluye el formato BOLT11, debe ser llenada con informaciĆ³n personal en la descripciĆ³n y luego entregada al servicio. Lo delicado es que esa informaciĆ³n se puede almacenar y compartir en una base de datos de usuarios. Lo mismo pasa con los nodos, cuya informaciĆ³n puede parar en manos de reguladores y gobiernos.
Para Armdxxi, eso es mƔs que suficiente para recomendar a los desarrolladores de monederos compatibles con la red Lightning a que eliminen la posibilidad de que los usuarios firmen declaraciones con sus nodos.
Ā«Al igual que con la eliminaciĆ³n generalizada de AOPP de las carteras de hardware/software, los exchanges pueden dejar de esperar que los usuarios sean capaces de entregar esta informaciĆ³n con facilidadĀ», expresĆ³ el desarrollador.
Motivo de pago, la otra manera
La segunda manera en que se puede estar facilitando la regla de viaje en la red Lightning es con la agregaciĆ³n de motivos de pago en las transacciones bajo el formato BOLT11. AcĆ” el papel lo juega el receptor de fondos.
Si bien en teorĆa el pagador y el beneficiario son los Ćŗnicos que conocen el motivo del pago, los Ā«custodiosĀ» de fondos pudieran ver y almacenar esa informaciĆ³n.
Por eso, alerta el desarrollador, si los exchanges transmiten facturas a empresas de anĆ”lisis de blockchains, como Chainalysis o Messari, Ā«podrĆa ser bastante reveladorĀ», en el entendido de que se podrĆa conocer, por ejemplo, el nombre de usuario interno que estĆ” pagando, quĆ© nodo de Lightning estĆ” recibiendo el envĆo, el monto total y la descripciĆ³n.
Esta informaciĆ³n recopilada en masa permite mapear puntajes de riesgo en toda la red. Estas puntuaciones de riesgo darĆ”n lugar a problemas de censura. AdemĆ”s, pueden compartir propietarios de nodos sospechosos y sus transacciones conocidas con partes malintencionadas.
Armdxxi, desarrollador de la red Lightning.
Para el especialista, esto puede subsanarse comunicando claramente que la informaciĆ³n que los usuarios ingresan en las facturas podrĆa ser verificada por terceras partes. No obstante, lo ideal es que los desarrolladores de monederos eliminen las descripciones por completo, sugiriĆ³.
Plegados a la regla de viaje
Esta posible vulneraciĆ³n de la privacidad en la red Lightning de Bitcoin se conoce tras haberse hecho viral el caso de los monederos de criptomonedas que decidieron plegarse a la recomendaciĆ³n del Grupo de AcciĆ³n Financiera Internacional (GAFI) para operar en Suiza y los PaĆses Bajos.
Tal como lo reportĆ³ CriptoNoticias hace unos dĆas, empresas como Trezor, BitBox y BlueWallet integraron en sus productos un protocolo que envĆa automĆ”ticamente a los exchanges una prueba de propiedad de monederos los personales.
Si bien Trezor reculĆ³ al dĆa siguiente y desistiĆ³ de incorporar el cuestionado protocolo (posiblemente impulsado por el duro repudio de la comunidad bitcoiner) otras empresas de su competencia perduraron con la decisiĆ³n.
AsĆ, y dado el impacto y crecimiento de la red Lightning de Bitcoin, resulta importante el aporte del desarrollador, cuya intenciĆ³n es velar por la privacidad ante todas las cosas.
Actualmente se estĆ” explotando lo suficiente con las facturas de BOLT11, por lo que deberĆamos preocuparnos por esto. Mi recomendaciĆ³n es eliminar la posibilidad de que los usuarios se disparen en el pie. Esto puede suceder hoy en la capa de aplicaciĆ³n al eliminar las descripciones de los monederos. La falta de soporte de descripciĆ³n ayudarĆ” a obstaculizar la capacidad de vigilancia masiva en el espacio Lightning.
Armdxxi, desarrollador de la red Lightning.
