XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks

Resumen

XMRMesh estudia si una transacción de Monero firmada puede viajar de teléfono en teléfono por una malla Bluetooth Low Energy del estilo de BitChat hasta que alguien con conexión la envíe. El diseño separa cinco estados que no deben confundirse: la preparación sin conexión, la entrega por la malla (con el mejor esfuerzo), el envío por una pasarela, la observación en el mempool y la confirmación en cadena.

No es dinero al portador sin conexión: una transacción firmada puede entrar en conflicto con otro gasto hasta que el consenso de Monero acepte una de las dos. Entregar algo de valor exige la confirmación en cadena o aceptar de forma explícita el riesgo de cero confirmaciones.

Abstract (original, en inglés)

This paper presents XMRMesh, a proposed design and unvalidated engineering draft for relaying signed Monero transactions over a BitChat-style Bluetooth Low Energy mesh until a connected peer can submit them. The design separates offline preparation, best-effort mesh delivery, gateway submission, mempool observation, and chain confirmation. Native Android/iOS wallet engines demonstrate cache-based offline construction in private regtest. Separately, the native constructor produced a complete public-stagenet payment: a 1,524-byte transaction constructed from 10,133,567 cached public outputs, submitted through Tor, observed in mempool and independently verified at block 2236657. This establishes construction, signing and gateway delivery, not physical BLE transport, radio performance, or a privacy guarantee. We define an initial transaction-fragment profile using canonical RingCT identifiers, 470 data bytes per fragment and real packet lengths. Other messages remain experimental. Bloom-filter key-image gossip is analyzed only as a non-authoritative hint with bandwidth, censorship, merge, denial-of-service, and privacy risks. The detection equation 1 − e^−λΔt, its rates, the 50–500 kbps budgets, latency model, and throughput arithmetic remain conditional illustrations rather than calibrated results. We make no claim of bounded loss, aggregate scalability, negligible energy, fixed fiat fees, absolute privacy, or safe zero-confirmation acceptance. The remaining roadmap requires physical Android/iOS BLE experiments.

Palabras clave: Monero; mobile mesh networks; Bluetooth Low Energy; offline payments; privacy; censorship resistance; store-and-forward; key images; double-spend detection.

Lo que aporta

• Un diseño de sistema y un perfil inicial de fragmentos para llevar transacciones de Monero en un sobre del estilo de BitChat. No es todavía una especificación completa a nivel de paquete.
• Un cotilleo (gossip) de key images, comprimido con filtros Bloom, que solo da pistas: nunca resuelve un conflicto de forma autoritativa.
• Un modelo de viabilidad con parámetros explícitos de carga, caudal, descubrimiento y ciclo de trabajo; sus cifras son supuestos, no mediciones.
• Un análisis de amenazas: metadatos de radio, relés maliciosos, vecindarios Sybil, pasarelas que retienen, envenenamiento de filtros y cachés de señuelos caducadas.
• Una hoja de ruta de implementación y validación que separa la simulación sintética de la evidencia real de Monero, Bluetooth, Tor y confirmación en cadena.

Evidencia hasta hoy

• Motores nativos de cartera en Android e iOS construyen transacciones sin conexión a partir de una caché, en un regtest privado.
• Un pago completo en el stagenet público: una transacción RingCT de 1.524 bytes, construida sin conexión con una instantánea de 10.133.567 salidas públicas, enviada por Tor, vista en el mempool y verificada de forma independiente en el bloque 2.236.657. Ocupa cuatro fragmentos de 470 bytes de datos.
• Vectores sintéticos de fragmentación y reensamblado con el identificador canónico de RingCT: 470 bytes de datos en un TX_FRAGMENT completo de 486 bytes.

Esto demuestra la construcción, la firma y la entrega por pasarela; no el transporte Bluetooth físico, el rendimiento de radio ni una garantía de privacidad.

Límites

• El relé por Bluetooth entre teléfonos físicos todavía no se ha probado.
• No hay garantía de privacidad: quedan metadatos de radio, de tiempos y de tamaño, y Tor solo oculta la IP de la pasarela al nodo que la recibe.
• Las pistas de key images tienen costes de ancho de banda, censura, denegación de servicio y privacidad que pueden superar su beneficio, que no se ha medido.
• La ecuación de detección, sus tasas, los presupuestos de 50–500 kbps, el modelo de latencia y la aritmética de caudal son ilustraciones condicionales, no resultados calibrados.
• Siguen abiertos la procedencia y la antigüedad segura de la caché de señuelos (30 días es solo una hipótesis), los esquemas de avisos y confirmaciones, y la política contra la denegación de servicio.
• No hay revisión independiente.

Hoja de ruta

• M0: congelar el perfil inicial: esquemas del sobre y de TX_FRAGMENT, límites y vectores multiplataforma.
• M1: vectores oficiales de cartera (blob, txid y validación completa) y requisitos de la caché sin conexión.
• M2: un pago real en stagenet entre al menos dos dispositivos físicos: construcción y firma sin conexión, relé Bluetooth, envío por Tor y confirmación independiente.
• M3–M4: matriz física Android/iOS, experimento de cotilleo con más de cinco dispositivos y endurecimiento multiplataforma.

Leer y citar

El enlace oficial es el DOI de Zenodo, donde el PDF se puede ver y descargar. La versión 1.7 tiene el DOI 10.5281/zenodo.23762733; el DOI de todas las versiones es 10.5281/zenodo.23739901.

El diseño se explica sin tecnicismos en BV-XMRM · XMRMesh.

Cómo citarlo:

BiVelio Inc (2026). XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks. Version 1.7. BiVelio Research, Privacy & Cryptographic Systems Series, Paper BV-XMRM, No. 1. CC0 1.0. https://doi.org/10.5281/zenodo.23762733

Documento en dominio público (CC0 1.0). Los derivados de software para Android siguen la GPLv3 y los de iOS, la Unlicense de sus componentes de origen.