XMRMesh: Offline Monero Payments over Bluetooth Low Energy Mesh Networks

Synthèse

XMRMesh étudie si une transaction Monero signée peut passer de téléphone en téléphone sur un maillage Bluetooth Low Energy de type BitChat jusqu'à ce qu'un appareil connecté la soumette. La conception sépare cinq états à ne pas confondre : la préparation hors ligne, la livraison par le maillage (au mieux), la soumission par une passerelle, l'observation dans le mempool et la confirmation sur la chaîne.

Ce n'est pas de la monnaie au porteur hors ligne : une transaction signée peut entrer en conflit avec une autre dépense jusqu'à ce que le consensus de Monero en accepte une. Remettre un bien de valeur exige la confirmation sur la chaîne ou l'acceptation explicite du risque à zéro confirmation.

Résumé original (en anglais)

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.

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

Contributions

• Une conception de système et un profil initial de fragments pour transporter des transactions Monero dans une enveloppe de type BitChat. Ce n'est pas encore une spécification complète au niveau des paquets.
• Une diffusion (gossip) de key images, compressée par filtres de Bloom, qui ne donne que des indices : elle ne tranche jamais un conflit de façon faisant autorité.
• Un modèle de faisabilité aux paramètres explicites de charge, débit, découverte et cycle d'activité ; ses chiffres sont des hypothèses, pas des mesures.
• Une analyse des menaces : métadonnées radio, relais malveillants, voisinages Sybil, passerelles qui retiennent, empoisonnement des filtres et caches de leurres périmés.
• Une feuille de route de mise en œuvre et de validation qui sépare la simulation synthétique des preuves réelles sur Monero, Bluetooth, Tor et la confirmation sur la chaîne.

Preuves à ce jour

• Des moteurs de portefeuille natifs Android et iOS construisent des transactions hors ligne à partir d'un cache, sur un regtest privé.
• Un paiement complet sur le stagenet public : une transaction RingCT de 1 524 octets, construite hors ligne à partir d'un instantané de 10 133 567 sorties publiques, soumise via Tor, vue dans le mempool et vérifiée de façon indépendante au bloc 2 236 657. Elle occupe quatre fragments de 470 octets de données.
• Des vecteurs synthétiques de fragmentation et de réassemblage avec l'identifiant canonique RingCT : 470 octets de données dans un TX_FRAGMENT complet de 486 octets.

Cela démontre la construction, la signature et la livraison par passerelle ; pas le transport Bluetooth physique, les performances radio ni une garantie de confidentialité.

Limites

• Le relais Bluetooth entre téléphones physiques n'a pas encore été testé.
• Aucune garantie de confidentialité : il reste des métadonnées radio, temporelles et de taille, et Tor ne cache l'IP de la passerelle qu'au nœud qui la reçoit.
• Les indices de key images ont des coûts de bande passante, de censure, de déni de service et de confidentialité qui peuvent dépasser leur bénéfice, non mesuré.
• L'équation de détection, ses taux, les budgets de 50–500 kbps, le modèle de latence et l'arithmétique de débit sont des illustrations conditionnelles, pas des résultats calibrés.
• Restent ouverts la provenance et l'âge sûr du cache de leurres (30 jours n'est qu'une hypothèse), les schémas d'avis et d'accusés de réception, et la politique contre le déni de service.
• Il n'y a pas de relecture indépendante.

Feuille de route

• M0: figer le profil initial : schémas de l'enveloppe et de TX_FRAGMENT, limites et vecteurs multiplateformes.
• M1: vecteurs officiels de portefeuille (blob, txid et validation complète) et exigences du cache hors ligne.
• M2: un vrai paiement sur stagenet entre au moins deux appareils physiques : construction et signature hors ligne, relais Bluetooth, soumission via Tor et confirmation indépendante.
• M3–M4: matrice physique Android/iOS, expérience de diffusion sur plus de cinq appareils et durcissement multiplateforme.

Lire et citer

Le lien officiel est le DOI de Zenodo, où le PDF peut être consulté et téléchargé. La version 1.7 a le DOI 10.5281/zenodo.23762733 ; le DOI de toutes les versions est 10.5281/zenodo.23739901.

La conception est expliquée sans jargon dans BV-XMRM · XMRMesh.

Comment la citer :

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 dans le domaine public (CC0 1.0). Les logiciels dérivés pour Android suivent la GPLv3 et ceux pour iOS, l'Unlicense de leurs composants d'origine.