BLOG |
Blink announcements
Cómo un atacante usó una falla en nuestras herramientas administrativas para llevarse 6.61 BTC de 24 cuentas, cómo restituimos cada una y qué hemos cambiado.
El sábado 19 de septiembre, a las 11:39 UTC, un cliente llamó al teléfono de uno de nuestros ingenieros para decirle que su saldo en Blink había desaparecido. Quince minutos después habíamos apagado todo el servicio custodial. Esa misma noche la falla estaba cerrada. El jueves siguiente, cada cliente afectado tenía de vuelta su saldo exacto, pagado por los accionistas de Blink. Ningún cliente asume pérdida alguna.
A los 22 clientes a quienes les robaron bitcoin, y a las 3,817 personas cuyos datos de cuenta fueron consultados: lo sentimos.
Qué pasó. Un atacante abrió una cuenta común y gratuita de Blink el 17 de septiembre. Dos días después aprovechó una falla en la forma en que nuestras herramientas administrativas verificaban los permisos para darle a esa cuenta poderes de administrador. Con esos poderes cambió el correo electrónico o el número de teléfono de 35 cuentas, inició sesión en ellas como si fuera su titular, subió los límites de retiro de 14 y retiró bitcoin de 24 entre las 09:51 y las 11:54 UTC, en parte on-chain y en parte por Lightning, a través del flujo que construimos para ayudar a los clientes a pasar a la autocustodia. El atacante obtuvo unos 6.61 BTC.
De quién era el dinero. El atacante apuntó a 36 cuentas custodiales. Una se salvó por casualidad: sus intentos de cambiar el correo electrónico fallaron y pasó a otra. De las 35 que tomó, retiró fondos de 24. Nueve tenían autenticación de dos factores y no perdieron nada (ver más abajo), y de las dos últimas tomó el control apenas minutos antes de que apagáramos el servicio, así que de ellas no se movió nada. Veintidós de las 24 cuentas vaciadas eran de clientes; dos eran de empresas del grupo Blink. Cada una recuperó su saldo exacto previo al incidente el 24 de septiembre, con la devolución de las comisiones de retiro, y las cuentas bloqueadas se reabrieron a partir de ese día. Blink asume la pérdida.
Lo que no tocó. El dinero salió de nuestra billetera operativa, el saldo que mantenemos para los pagos del día a día. La mayoría de los fondos de los clientes está en almacenamiento en frío con firma múltiple, que requiere varias llaves en manos de personas distintas, y nada en nuestras herramientas administrativas puede alcanzarlo. Las cuentas no custodiales nunca estuvieron en juego: no tenemos esas llaves, así que el atacante no tenía nada que llevarse.
Lo que vio. Durante el ataque también consultó datos de otras 3,817 cuentas. En algunos casos incluían un número de teléfono o un correo electrónico. No vio nombres, documentos de identidad, direcciones, contraseñas ni frases semilla. Escribimos a cada titular que pudimos contactar con el detalle de lo que se vio.
Lo que frenó el ataque. La autenticación de dos factores. Ninguna de las 24 cuentas vaciadas la tenía activada. Nueve de las cuentas atacadas sí. El atacante inició sesión en las nueve, pero cada uno de sus 18 intentos de usarlas fue rechazado. Cero pérdidas. Lo señalamos porque es una de las principales lecciones de este incidente: el 2FA funcionó, y debimos exigirlo para retiros grandes y para cuentas con saldos altos.
Lo que cambiamos. La falla se cerró el mismo día, y una tercera capa de protección entró en producción el 21 de septiembre. Las herramientas administrativas ya no están expuestas a internet. Las funciones administrativas que cambian el correo o el teléfono de un cliente están desactivadas para todos mientras las rediseñamos. Se revocaron todas las claves de API de los clientes. La billetera operativa guarda ahora una fracción de lo que guardaba. La lista completa está más abajo.
Dónde está el dinero. Una parte sigue en las direcciones a las que el atacante retiró los fondos. El resto pasó a otras billeteras suyas, desde donde unos 5 BTC salieron por un servicio de intercambio entre cadenas y una cantidad pequeña llegó a Binance. En El Salvador se presentó una denuncia penal ante la Fiscalía General de la República y se notificó al regulador financiero; en Próspera ZEDE se presentó una denuncia penal ante la policía y se notificó al regulador financiero. No esperamos recuperar el dinero; la recompensa de abajo es para quien pueda cambiar eso.
Una recompensa del 50%. Pagaremos el 25% del valor de cualquier parte de los 6.61 BTC robados el 19 de septiembre que se recupere como resultado directo de información que tú nos des: hasta unos 1.65 BTC si se recuperara todo. Otro 25% de todo lo que se recupere irá a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares de Bitcoin del Sur Global que elijan en conjunto. Si la información lleva a que se congelen fondos, la recompensa se paga cuando esos fondos vuelvan a una billetera que controlamos. La oferta no tiene fecha de vencimiento. Escribe a bounty@blinkbtc.com. Los términos completos, que son los que rigen, están en blink.sv/bounty-terms.
Qué debes hacer. Activa la autenticación de dos factores (Configuración → Seguridad y privacidad → Autenticación de dos factores) y actívala también en tu correo electrónico. Si solo entras con tu número de teléfono, agrega un correo electrónico para iniciar sesión: un número de teléfono puede ser robado con un duplicado de SIM (SIM swap). Si usas la API, crea una clave nueva. Ignora cualquier correo o SMS sobre este incidente que traiga un enlace: a los usuarios afectados les escribimos con mensajes dentro de la app de Blink. Nunca te pediremos tu PIN, tu contraseña, tu frase semilla ni un código de acceso, ni que muevas tus fondos. Si te escribimos sobre tu cuenta, sigue los pasos de ese mensaje. Si prefieres guardar tus propias llaves, las cuentas no custodiales están en la app desde junio (Configuración → Migrar a no custodia).
Blink lo operan unas veinte personas en una docena de husos horarios, así que no existe un sábado por la mañana para todos a la vez. A las 11:39 UTC caía la noche en Hong Kong, era la hora del almuerzo en Europa y todavía no amanecía en El Salvador. El cliente que llamó había notado que su saldo estaba en cero y que habían cambiado su correo electrónico. En menos de seis minutos el equipo estaba en una llamada, las primeras cuentas estaban bloqueadas a mano desde el panel administrativo y se había tomado la decisión que importaba: apagarlo todo.
A las 11:54 desconectamos todo el sistema custodial. Esa decisión le costó a cada usuario de Blink casi ocho horas de servicio. Los retiros se detuvieron en el momento en que se detuvo el servicio. A las 12:41 publicamos el primer aviso público: servicios en pausa, investigando. A las 16:06 publicamos el segundo: cada cuenta afectada será restituida por completo.
A las 16:17 estaba integrada la primera corrección y a las 17:50 la tercera. Los fondos restantes de la billetera operativa se movieron a direcciones nuevas para que cualquier pago ya firmado para los retiros del atacante rebotara. A las 19:34 volvimos a encender el servicio para todos, menos para las 36 cuentas que el atacante había tocado, que siguieron bloqueadas hasta que pudiéramos restituirlas correctamente. Las funciones administrativas que cambian datos de contacto siguieron congeladas como segundo candado, la corrección se verificó en el entorno de pruebas esa misma noche y, en los días siguientes, repetimos nosotros mismos todo el ataque contra una copia del código anterior a la corrección, para asegurarnos de entenderlo, y confirmamos que cada capa ahora lo detiene.
Todas las horas están en UTC; El Salvador está seis horas atrás.
Desde octubre de 2023 hasta el 19 de septiembre de 2026, cualquier persona con una cuenta gratuita de Blink y un navegador podía darse a sí misma los poderes de nuestro equipo de soporte: cambiar el correo electrónico o el número de teléfono de la cuenta de cualquier cliente, luego iniciar sesión como ese cliente y subir sus límites de retiro. Publicamos exactamente cómo, porque nuestro código es abierto, otros servicios operan despliegues construidos a partir de él, y el error de fondo —confiar en lo que un token dice de sí mismo sobre lo que tiene permitido hacer— puede cometerse en cualquier sistema construido de la misma manera.
Nuestro equipo usa una interfaz administrativa para ayudar a los clientes: desbloquear una cuenta, corregir un número de teléfono, subir un límite. El acceso pasa por OAuth2, el mismo estándar que te permite iniciar sesión en un sitio web con tu cuenta de otro. Había tres cosas mal, y ninguna de ellas, por sí sola, llama la atención.
La pantalla de consentimiento confiaba en el navegador. Cuando una aplicación pide permisos, nuestra página de consentimiento tomaba la lista de permisos directamente del formulario que enviaba el navegador y se la pasaba tal cual a nuestro servidor OAuth. Nunca comparaba esa lista con lo que la aplicación había pedido realmente. Así que cualquiera podía agregar al formulario un campo oculto que dijera "dame también permisos de administrador", y el servidor —que confiaba, con razón, en su propia página de consentimiento— emitía un token perfectamente válido que decía "administrador".
La API administrativa confiaba en cualquier token. El guardián de acceso que tiene delante aceptaba cualquier token vigente de nuestro servidor OAuth: sin exigir ningún permiso, sin verificar que el token estuviera destinado a la API administrativa y sin verificar quién era el cliente. Copiaba los permisos que el token declaraba tener en la credencial que usa el servidor administrativo.
El servidor administrativo confiaba en el texto de los permisos. Si el texto decía administrador, eras administrador. No había ninguna verificación de que la persona detrás del token fuera un administrador conocido.
Juntas, estas tres fallas hacían que bastaran una cuenta gratuita y un navegador. No se usó ninguna cuenta ni credencial del personal, y no hubo malware. Nuestro propio sistema de identidad emitió esos tokens, y por eso mismo no saltó ninguna alarma. El atacante probó primero la vía obvia —agregar permisos en la solicitud de autorización principal— y nuestra configuración la rechazó correctamente. Luego probó la página de consentimiento, y por ahí sí pudo pasar.
Para quien audite un stack similar, la historia importa. El hueco se abrió en octubre de 2023 con tres pull requests seguidos: el primero hizo que la API administrativa aceptara tokens OAuth mientras una verificación de editor separada seguía protegiéndola; el segundo eliminó esa verificación de editor; el tercero dio a todos los usuarios acceso a la pantalla de consentimiento de OAuth. Un cambio de refuerzo en mayo de 2026 (PR #158) agregó requisitos de permisos administrativos en el servidor administrativo, pero leía esos permisos del propio token, y la página de consentimiento seguía permitiendo que cualquiera los pusiera ahí. Se pudo explotar durante unos tres años.
Las correcciones son públicas: la página de consentimiento ahora rechaza cualquier permiso que la aplicación no haya pedido (PR #853); los tokens administrativos deben llevar una audiencia emitida solo para la API administrativa, que los tokens de los clientes no pueden obtener (el mismo PR; el PR #855 nos permitió activar esta verificación en producción por separado, y lo hicimos el 21 de septiembre); y las funciones administrativas que cambian datos de contacto pueden congelarse por completo mediante configuración, para todos (PR #861).
El código se escribió en 2023, dentro de la empresa donde se construyó la plataforma Blink desde 2019, y pasó a ser nuestro en octubre de 2024, cuando Blink pasó por un cambio de propiedad y se convirtió en una empresa independiente. Dos de los ingenieros que habían construido la plataforma vinieron con nosotros, pero los que habían escrito el flujo de autorización administrativa no, así que nadie en el equipo de Blink sabía por qué existía una verificación de permisos anterior. Durante 2025, la mayor parte de nuestro trabajo de ingeniería se dedicó a separar nuestros sistemas de los de esa empresa, que con los años se habían entrelazado: nuestra propia infraestructura, nuestras propias cuentas, nuestro propio nodo.
En 2026 la regulación cambió en muchos de los países donde operábamos. Google empezó a exigir licencias locales para las aplicaciones de billetera en quince mercados, el período de transición de las reglas MiCA de la Unión Europea terminó el 1 de julio, y muchas otras jurisdicciones aprobaban leyes nuevas o ponían en vigor leyes aprobadas en años anteriores. Respondimos guardando menos dinero de nuestros clientes en lugar de solicitar más licencias: construimos y lanzamos una billetera no custodial, retiramos el servicio custodial de más de cuarenta jurisdicciones y trasladamos a decenas de miles de usuarios a cuentas en las que ellos guardan sus propias llaves. Nuestra publicación de junio sobre el lanzamiento de las cuentas no custodiales describe ese trabajo. Para un equipo de unas veinte personas, eso tomó la mayor parte del año.
Reforzar el código que habíamos heredado quedó detrás de esos dos proyectos. Esperó demasiado. Lo primero que cambiamos fue cómo se clasifican y se asignan los hallazgos de seguridad.
La billetera operativa elevada es parte de la misma historia. La teníamos a aproximadamente el doble de su nivel normal como colchón para la migración, cuya primera ola había terminado una o dos semanas antes del ataque. Todavía no la habíamos bajado. Por eso la pérdida pudo ser tan grande. Desde entonces la redujimos a una fracción de ese nivel, y el saldo operativo de Lightning se está reduciendo aún más.
El atacante tomó 35 cuentas de la misma manera: cambiar el correo electrónico o el número de teléfono con las herramientas administrativas, pedir un código de acceso, iniciar sesión. De 24 retiró fondos. En nueve chocó contra un muro. Esas nueve tenían activada la autenticación de dos factores —una app autenticadora en el teléfono del titular— y, en una cuenta protegida con 2FA, una sesión abierta solo con un código de acceso no puede mover dinero. Nuestros registros muestran que los 18 intentos del atacante en esas nueve cuentas fallaron exactamente en ese control. Cero pérdidas en cada una.
El 2FA no impidió la toma de nuestras herramientas administrativas. Pero sí impidió el robo de fondos de las cuentas individuales. Ninguna de las 24 cuentas que perdieron dinero lo tenía activado. Debimos exigirlo para retiros grandes y para cuentas con saldos altos.
Si haces una sola cosa después de leer esto, que sea esta: Configuración → Seguridad y privacidad → Autenticación de dos factores. Luego actívala también en tu correo electrónico, porque ahí pueden llegar tus códigos de acceso a Blink.
El domingo, un día después del ataque, sabíamos qué se había tomado y de quién, al satoshi, conciliado con el libro contable, la blockchain y el nodo de Lightning, y la Junta Directiva había decidido cómo pagarlo. Los accionistas de Blink comprometieron el monto completo en menos de 24 horas como préstamo sin intereses, lo adelantaron el miércoles, y a cada accionista se le ha ofrecido financiar su parte en las mismas condiciones. El jueves 24 de septiembre restituimos cada saldo afectado y devolvimos las comisiones que habíamos cobrado por los retiros fraudulentos. Los clientes afectados recibieron un mensaje directo nuestro antes de que dijéramos nada más en público, y también las personas cuyos datos fueron consultados.
El orden fue deliberado. Primero, restituir a los usuarios; todo lo demás, después. El viernes informamos a nuestros accionistas con los mismos hechos que estás leyendo ahora, y retuvimos esta publicación hasta que las autoridades tuvieran nuestros informes: una denuncia penal ante la Fiscalía General de la República de El Salvador, avisos al regulador financiero y a la agencia de ciberseguridad de El Salvador, una denuncia penal ante el Departamento de Policía de Próspera ZEDE y un aviso al regulador financiero de Próspera.
Hay dos cosas de esa semana que queremos dejar registradas. El domingo, el atacante nos escribió exigiendo un pago, con la amenaza de publicar datos de usuarios. No pagamos y no lo haremos; ese mensaje es ahora prueba de su intento de extorsión. Y del domingo al miércoles siguió iniciando sesión en cuatro de las cuentas bloqueadas cuyos datos de contacto todavía tenían el correo del atacante, porque aún no las habíamos restablecido. Cada pago que intentó fue rechazado y no se movió nada. No debió haber sido posible. Nuestro procedimiento de reactivación ahora restablece primero los datos de contacto, cierra todas las sesiones y solo entonces desbloquea la cuenta.
No somos la primera empresa que absorbe una pérdida así y restituye a sus usuarios. Exchanges y billeteras lo han hecho antes que nosotros. La pérdida de un custodio le corresponde al custodio.
Blink no partía de cero el 19 de septiembre. La mayoría de los fondos de los clientes ya estaba en almacenamiento en frío con firma múltiple, repartido en varios continentes; el servicio opera con reserva completa; la autenticación de dos factores estaba disponible y llevábamos tiempo animando a los usuarios a activarla; y los retiros estaban limitados según el nivel de la cuenta. Casi todo eso resistió: el atacante nunca llegó al almacenamiento en frío, nunca tocó una cuenta no custodial y fracasó en cada cuenta que tenía 2FA. Lo que falló, en concreto, fueron las verificaciones de autorización de las herramientas administrativas que heredamos, y un monitoreo que vigilaba las caídas del servicio y no a un administrador haciendo algo que ningún administrador debería hacer. Lo que falló, en general, fueron nuestras prioridades: el cambio de propiedad y luego la migración fuera de la custodia ocuparon a la mayor parte del equipo, y el trabajo de seguridad sobre el código heredado quedó detrás.
Lo que hicimos en los primeros días:
Se sigue reforzando toda la plataforma.
Y dos compromisos que empiezan hoy:
1.La recompensa por recuperación. Pagaremos el 25% del valor de cualquier parte de los 6.61 BTC robados el 19 de septiembre que se recupere como resultado directo de información que tú nos des: hasta unos 1.65 BTC si se recuperara todo. De todo lo que se recupere, otro 25% irá a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares de Bitcoin del Sur Global que elijan en conjunto y que puedan necesitar un respaldo adicional. La oferta no tiene fecha de vencimiento; escribe a bounty@blinkbtc.com. La recompensa solo se paga con fondos que hayan vuelto a una billetera que controlamos. Los fondos robados se pueden devolver on-chain a bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 o por Lightning a la dirección Lightning bounty@blink.sv.
2.Un canal para reportar problemas de seguridad, con recompensas. Escribe a bounty@blinkbtc.com. Acusamos recibo de cada reporte en un plazo máximo de 72 horas, y nuestro grupo de seguridad se hace cargo de él hasta resolverlo. La investigación de buena fe sobre el software de Blink es bienvenida, y no emprenderemos acciones contra nadie que reporte una vulnerabilidad de forma responsable. Pagamos recompensas discrecionales de hasta 0.1 BTC por hallazgos críticos. La política completa está en blink.sv/bounty-terms. Este canal existe por este incidente: cada reporte debe llegar a algún lado, recibir respuesta y tener un responsable hasta que se resuelva.
El 50% se divide en dos: el 25% es para quien aporte la información que lleve a una recuperación, y otro 25% de todo lo que se recupere va a Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera y a las economías circulares que ellos elijan. Creemos que lo más probable es que los fondos estén perdidos para siempre. Recuperar bitcoin robado es muy difícil, así que para nosotros cualquier monto recuperado es una gran victoria, y cuantas más personas animemos a ayudarnos a encontrar al atacante, mejor. Alguien así no debería salirse con la suya tan fácilmente, y queremos que gastar ese dinero le resulte lo más difícil e incómodo posible.
Agregamos el segundo 25% porque queremos recordarle al atacante que robó dinero que nosotros y nuestros accionistas, comprometidos con nuestra misión, habríamos preferido mil veces destinar a apoyar la adopción de Bitcoin desde las bases y a impulsar a quienes construyen con Bitcoin en comunidades sin acceso a la banca en todo el mundo. Debería darle vergüenza.
Hemos rastreado los fondos sin interrupción desde el 19 de septiembre. Al 1 de octubre, unos 0.87 BTC seguían sin moverse en las direcciones receptoras. El resto pasó a otras billeteras del atacante, que también guardan bitcoin que no salió de Blink. Desde esas billeteras, unos 5.05 BTC salieron por un servicio de intercambio entre cadenas (NEAR Intents): 1 BTC el 21 de septiembre y unos 4.05 BTC el 28 y 29 de septiembre. Nuestra propia solicitud de preservación de datos del 22 de septiembre quedó sin respuesta, y hemos pedido a las autoridades que obtengan los registros de ese servicio. Unos 0.012 BTC llegaron a un depósito en Binance, y el equipo de seguridad de Binance está colaborando y bloqueándolos. Como hay bitcoin propio del atacante mezclado, estas cifras no suman los 6.61 BTC. Las direcciones on-chain están en el anexo.
Nuestro código es abierto, y servicios que no construimos operan despliegues derivados de él. El patrón vulnerable —un flujo de consentimiento que confía en la lista de permisos del navegador y un guardián de acceso que acepta cualquier token vigente sin verificar la audiencia— es anterior a los repositorios actuales de Blink y está en el historial público archivado. Hemos avisado en privado a los operadores de despliegues derivados que conocemos; uno aplicó la corrección el mismo día. Nuestro aviso de seguridad para el código se publicará en GitHub en github.com/blinkbitcoin/blink/security/advisories, con un identificador CVE solicitado. Si operas algo construido sobre el código de Blink y no has sabido de nosotros, escribe a bounty@blinkbtc.com; una vez que confirmemos que operas un despliegue, te compartiremos el procedimiento de verificación completo y te ayudaremos a comprobarlo. Las correcciones son los tres PR enlazados arriba. Los atacantes ahora escanean el código público a velocidad de máquina. Si operas este código, revísalo hoy.
Blink nació como la billetera de Bitcoin para el día a día de un pequeño pueblo de playa donde la gente necesitaba dinero que funcionara. El 19 de septiembre, para 22 de nuestros clientes, no funcionó. Cada uno de ellos nos había confiado su dinero, que es lo único para lo que existe un custodio.
A nuestros clientes, por su paciencia; a los investigadores y exchanges que ayudaron en cuestión de horas; a los accionistas que respaldaron a la empresa sin dudarlo; y al equipo que dejó todo un sábado y no durmió: gracias. Recuperaremos la confianza como se ganó en El Zonte: estando presentes y logrando que los pagos pasen, todos los días.
¿Mi dinero estuvo en riesgo? Si tu cuenta está abierta y no te escribimos, no tenemos registro de que el atacante haya consultado los datos de tu cuenta, y no se tomó nada de ella. Hasta que la cerramos el 19 de septiembre, la falla podía usarse contra cualquier cuenta custodial, aunque en una cuenta con 2FA no habría permitido mover dinero. La mayoría de los fondos de los clientes está en almacenamiento en frío, que las herramientas administrativas no pueden alcanzar. Si tienes una cuenta no custodial, tus llaves nunca estuvieron en nuestros servidores y el atacante no tenía nada que llevarse.
¿El atacante obtuvo mis datos? Consultó datos de 3,817 cuentas. Escribimos a cada titular que pudimos contactar con lo que se vio. Si tu cuenta está abierta y no recibiste ese mensaje, no estuvo entre ellas. Siempre puedes preguntarnos qué se consultó de tu cuenta, si es que se consultó algo: support@blink.sv.
¿Por qué el monitoreo de Blink no detectó el ataque? Nuestras alertas estaban hechas para detectar caídas del servicio. No tenían ninguna regla para un administrador que hace cosas que ningún administrador debería hacer, y el atacante usaba nuestras propias herramientas con tokens que nuestro propio sistema había emitido.
¿Por qué había tanto en la billetera operativa? Habíamos duplicado aproximadamente nuestro saldo operativo como colchón para la migración a cuentas no custodiales, y no lo habíamos bajado después de que terminó la primera ola. Ahora está en una fracción de ese nivel, y no vamos a publicar la cifra.
¿El 2FA me habría protegido? En este incidente, sí. Cada cuenta que lo tenía conservó su dinero; ninguna de las cuentas que perdieron dinero lo tenía. No detendrá todos los ataques, pero detuvo este. Actívalo.
¿Debo pasarme a una cuenta no custodial? Si prefieres guardar tus propias llaves, sí: para eso existen, y nadie en Blink, ni nadie que logre entrar en Blink, puede mover los fondos que guardas tú. No es obligatorio, todavía no tiene todas las funciones y su disponibilidad depende de tu región. Si sigues con una cuenta custodial, activa el 2FA.
¿Quién pagó por esto? Los accionistas de Blink, con un préstamo sin intereses comprometido en menos de 24 horas y adelantado el 23 de septiembre. No los clientes ni las reservas de los clientes. Blink sigue operando con reserva completa: cada saldo está respaldado uno a uno.
Encontré un problema de seguridad en Blink. ¿Qué hago? Escribe a bounty@blinkbtc.com. Te responderemos en un plazo máximo de 72 horas, tu reporte tendrá un responsable hasta que se resuelva, y los hallazgos críticos tienen recompensa.
Aquí agregaremos, con fecha, las novedades sobre la recuperación, la recompensa y cualquier corrección a esta publicación.
Las siguientes direcciones recibieron los retiros on-chain. Pedimos a los exchanges y a los investigadores que filtren los depósitos que provengan de ellas y que escriban a bounty@blinkbtc.com. (Lo que salió por Lightning fue a billeteras Lightning controladas por el atacante y se rastrea por separado.)
Total on-chain: 4.62685758 BTC recibidos en estas direcciones en 14 retiros, siete de ellos a la primera dirección. Nuestro sistema de pagos agrupa los retiros, así que los 14 salieron en 12 transacciones on-chain. Los 1.98399667 BTC restantes del total de 6.61085425 BTC salieron por Lightning.
Start receiving and sending bitcoin now
