XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks

Resum

XMRMesh estudia si una transacció de Monero signada pot viatjar de telèfon en telèfon per una malla Bluetooth Low Energy de l'estil de BitChat fins que algú amb connexió l'enviï. El disseny separa cinc estats que no s'han de confondre: la preparació sense connexió, el lliurament per la malla (amb el millor esforç), l'enviament per una passarel·la, l'observació al mempool i la confirmació en cadena.

No són diners al portador sense connexió: una transacció signada pot entrar en conflicte amb una altra despesa fins que el consens de Monero n'accepti una. Lliurar alguna cosa de valor exigeix la confirmació en cadena o acceptar de manera explícita el risc de zero confirmacions.

Abstract (original, en anglè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.

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

Què aporta

• Un disseny de sistema i un perfil inicial de fragments per portar transaccions de Monero en un sobre de l'estil de BitChat. Encara no és una especificació completa a nivell de paquet.
• Un intercanvi (gossip) de key images, comprimit amb filtres Bloom, que només dona pistes: mai no resol un conflicte de manera autoritativa.
• Un model de viabilitat amb paràmetres explícits de càrrega, cabal, descobriment i cicle de treball; les seves xifres són supòsits, no mesures.
• Una anàlisi d'amenaces: metadades de ràdio, relés maliciosos, veïnats Sybil, passarel·les que retenen, enverinament de filtres i memòries cau d'esquers caducades.
• Un full de ruta d'implementació i validació que separa la simulació sintètica de l'evidència real de Monero, Bluetooth, Tor i confirmació en cadena.

Evidència fins avui

• Motors natius de cartera a Android i iOS construeixen transaccions sense connexió a partir d'una memòria cau, en un regtest privat.
• Un pagament complet a l'stagenet públic: una transacció RingCT de 1.524 bytes, construïda sense connexió amb una instantània de 10.133.567 sortides públiques, enviada per Tor, vista al mempool i verificada de manera independent al bloc 2.236.657. Ocupa quatre fragments de 470 bytes de dades.
• Vectors sintètics de fragmentació i reassemblatge amb l'identificador canònic de RingCT: 470 bytes de dades en un TX_FRAGMENT complet de 486 bytes.

Això demostra la construcció, la signatura i el lliurament per passarel·la; no el transport Bluetooth físic, el rendiment de ràdio ni una garantia de privadesa.

Límits

• El relé per Bluetooth entre telèfons físics encara no s'ha provat.
• No hi ha garantia de privadesa: queden metadades de ràdio, de temps i de mida, i Tor només amaga la IP de la passarel·la al node que la rep.
• Les pistes de key images tenen costos d'amplada de banda, censura, denegació de servei i privadesa que poden superar-ne el benefici, que no s'ha mesurat.
• L'equació de detecció, les seves taxes, els pressupostos de 50–500 kbps, el model de latència i l'aritmètica de cabal són il·lustracions condicionals, no resultats calibrats.
• Continuen oberts la procedència i l'antiguitat segura de la memòria cau d'esquers (30 dies és només una hipòtesi), els esquemes d'avisos i confirmacions, i la política contra la denegació de servei.
• No hi ha revisió independent.

Full de ruta

• M0: congelar el perfil inicial: esquemes del sobre i de TX_FRAGMENT, límits i vectors multiplataforma.
• M1: vectors oficials de cartera (blob, txid i validació completa) i requisits de la memòria cau sense connexió.
• M2: un pagament real a stagenet entre almenys dos dispositius físics: construcció i signatura sense connexió, relé Bluetooth, enviament per Tor i confirmació independent.
• M3–M4: matriu física Android/iOS, experiment d'intercanvi amb més de cinc dispositius i enduriment multiplataforma.

Llegir i citar

L'enllaç oficial és el DOI de Zenodo, on el PDF es pot veure i descarregar. La versió 1.7 té el DOI 10.5281/zenodo.23762733; el DOI de totes les versions és 10.5281/zenodo.23739901.

El disseny s'explica sense tecnicismes a BV-XMRM · XMRMesh.

Com citar-lo:

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

Document de domini públic (CC0 1.0). Els derivats de programari per a Android segueixen la GPLv3 i els d'iOS, la Unlicense dels seus components d'origen.