Maxwell Weekly

Los temas salen de los temarios que publican los BitDevs de cada ciudad. En los últimos 14 días hubo seminario en 7 sedes, y en las últimas 6 semanas en 22. Al lado de cada tema van las sedes que lo trataron, para poder recontarlo.

Los 5 temas que trataron más sedes en los últimos 14 días, con 2 como mucho de la misma materia.

Quedaron afuera porque su materia ya tenía 2:

• La ronda de septiembre: LDK v0.2.6, Core Lightning v26.06.8 y la divulgación de dos DoS que Eclair ya corrigió. En septiembre, LDK v0.2.6 y Core Lightning v26.06.8 corrigieron vulnerabilidades, y se divulgaron dos DoS que Eclair arregló en v0.14.0 [1][2][3]. (5 de 7 sedes en 14 días.) Fuentes: [1] github.com · v0.2.6 [2] github.com · v26.06.8 [3] delvingbitcoin.org · 2914

Ya recorrió la red

Estuvieron en el 60 % de las sedes o más en las últimas 6 semanas.

• Core Lightning v26.06.7 publicó primero los binarios y dos semanas después el código fuente de la versión. Core Lightning v26.06.7 salió el 28 de agosto sin publicar su código fuente hasta el 11 de septiembre, para que fuera más difícil reconstruir las fallas [1]. (15 de 22 sedes en 6 semanas.) Fuentes: [1] github.com · v26.06.7
• Sacaron unos 4.000 BTC de Liquid por vulnerabilidades de consenso y una brecha en la firma PAK de un miembro. Según el informe de Blockstream, un atacante retiró unos 4.000 BTC de Liquid y al 23 de septiembre había devuelto 3.400, con unos 602 pendientes [1]. (15 de 22 sedes en 6 semanas.) Fuentes: [1] blog.blockstream.com

Todavía no lo trató ninguna sede

Temas que encontró Max y que, cuando se relevaron, no figuraban en el temario de ninguna de las sedes BitDevs que se siguen.

• Escalar la red Lightning con reconciliación de conjuntos aplicadainéditotangible

  Los nodos Lightning conocen la topología de la red (canales y nodos) por gossip: cada uno reenvía a sus pares lo que recibe. Un paper del 16 de agosto de 2026 midió ese mecanismo y concluye que es estructuralmente ineficiente. Propone reemplazarlo por reconciliación de conjuntos, la idea que Erlay usa para las transacciones en la capa base: en vez de mandar todo, dos nodos intercambian solo la diferencia entre lo que cada uno tiene. En simulaciones sobre Core Lightning con capturas reales de gossip, la sincronización baja de horas a unos pocos minutos. Por qué importa ahora: es un trabajo reciente y no aparece en el relevamiento de temarios de otras sedes, según la ficha. Por qué a BitDevs Córdoba: hay un debate concreto para la sala. La especificación de Lightning (BOLT 7) ya trae primitivas de sincronización, y el paper dice que igual el resultado es ineficiente. ¿Falla el diseño o falla cómo se usa? Eso es para discutir, no para dar por resuelto.

  Problema: el gossip de Lightning es por inundación. Los autores dicen que sus mediciones lo muestran como "fundamentalmente ineficiente". Propuesta: compartir anuncios de canal, actualizaciones y anuncios de nodo con protocolos de reconciliación de conjuntos. Evalúan los enfoques existentes bajo condiciones de red realistas y proponen ADAPTIVEIBLT, un protocolo IBLT (Invertible Bloom Lookup Table) adaptativo, con una mejora de decodificación parcial. Evaluación: simulación de la reconciliación en Core Lightning con snapshots reales de gossip. El resultado que reportan es pasar de horas a pocos minutos. Punto de discusión: BOLT 7 ya define query_channel_range y reply_channel_range con checksums, query_short_channel_ids y gossip_timestamp_filter. También exige que un nodo no envíe gossip que no generó él mismo hasta recibir gossip_timestamp_filter. Es decir, el paper pisa mecanismo ya especificado. Esa lectura sale de la nota de la ficha, que cita BOLT 7. No la contrasté yo contra la spec. Autoría: la ficha dice que Trachtenberg es coautor del trabajo original de reconciliación de conjuntos que usa Erlay. No lo verifiqué. Tampoco leí el texto completo del paper, así que no puedo describir ADAPTIVEIBLT más allá del abstract. Quedan sin cubrir el tamaño de los conjuntos, los parámetros y la metodología de medición.

  Fuente

• Panel de salud del addrmaninédito

  El addrman es donde cada nodo guarda las direcciones de los pares que conoce. naiyoma comparte un panel para mirar su salud que, según el post, armó con stratospher y «vibe-coded for fun last month»: hecho con ayuda de IA, y lo dice. No continúa los hilos de BNOC sobre el spam de direcciones (163 y 164) que tiene address-relay-under-stress, pero mira la misma parte del nodo.

  Fuente

• Hacia nuevas buenas prácticas de autocustodiacontroversiainédito

  El incidente de entropía de COLDCARD llega solo a todas las sedes; lo que no llega es la otra mitad: qué se cambia a partir de mañana. Este post la escribe, y peleándose con el consenso actual — 2-de-2 en vez de 2-de-3; multi-vendor entendido como "sin código criptográfico compartido" (todas las hardware wallets usan la misma libsecp256k1); elegir 11 de las 12 palabras uno mismo de las 2048 del BIP39; 12 palabras y no 24; placas de acero punzadas y no grabadas; wipe y restore antes de fondear.

  Fuente