lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity
archy/docs/mesh-bitcoin.md
Dorian 12b5fb2d1b security hardening
2026-03-18 09:56:40 +00:00

20 KiB
Raw Blame History

Off-Grid Bitcoin Transaction Security Analysis

Comprehensive security analysis for off-grid Bitcoin transactions over mesh radio (LoRa/Meshcore) in the Archipelago context. Covers attack vectors, trust models, and mitigations for every layer of the stack.

1. Transaction Creation & Signing (Offline)

Offline signing is cryptographically safe. Bitcoin signing is a pure secp256k1 operation — no network needed. PSBT (BIP174) was designed exactly for this.

Key Risks

Attack Severity Trustless Fix? Description
Stale UTXO data High No — requires chain state UTXO already spent; tx is invalid. No fund loss, wastes time/bandwidth.
Address substitution on unsigned PSBT Critical Yes — verify on trusted display Compromised PSBT creator substitutes destination address.
Fee manipulation in PSBT Medium Yes — signer verifies fee Compromised PSBT creator inflates fees (theft to miners).
Double-spend by offline sender Critical No — fundamental Sender can sign conflicting txs; nothing is final until confirmed in a block.

PSBT Security Model

PSBTs are tamper-evident but not tamper-proof across a network. The signer verifies what they sign, but cannot prevent the PSBT creator from lying about context. In a mesh context:

  • Sign PSBTs on the local device only
  • Only send the fully-signed raw transaction over mesh for broadcast
  • Never send unsigned PSBTs over mesh — the relay could modify outputs

Archipelago Status

PsbtHash (type 3) sends only the SHA-256 hash over mesh, not the PSBT itself — correct. Actual PSBT exchange should happen on a trusted local channel (USB, QR code, NFC).

2. Transaction Broadcasting / Relay Trust

A signed Bitcoin transaction is cryptographically sealed by the sender's private key. The relay cannot:

  • Change the destination address
  • Change the amount or fee
  • Steal funds or extract the private key

The relay can:

  • Not broadcast it (censorship) — High severity
  • Delay broadcasting (enables race conditions) — High severity
  • Claim it broadcast when it didn't — High severity
  • Front-run (only relevant for DEX/DeFi trades, not standard payments)

Proof of Broadcast

There is no native Bitcoin "proof of broadcast." Mitigations:

  1. Relay returns signed attestation (Ed25519) with txid + timestamp
  2. Sender watches for confirmation via block header relay
  3. Multiple independent relays reduce collusion risk
  4. Relay returns actual sendrawtransaction RPC response from Bitcoin Core

Archipelago Status

TxRelayResponse returns the actual RPC result (txid, error, error_code) — good. However, the response is not signed by the relay, so a mesh MITM could forge it. TxConfirmation (type 12) provides follow-up confirmation updates (1, 2, 3 confirmations), which is the real proof.

Gap: Sign TxRelayResponse

Recommendation: Sign TxRelayResponse messages with the relay's Ed25519 key (using TypedEnvelope::new_signed). This prevents a mesh MITM from forging relay responses.

3. Payment Verification Without a Full Node

SPV (Simplified Payment Verification)

SPV clients download only block headers (80 bytes each) and verify:

  • Chain of proof-of-work is valid
  • Transaction is included in a block via Merkle proof

What SPV can verify:

  • Block header has valid proof-of-work
  • Transaction included in a specific block (via Merkle proof)
  • Which chain has the most cumulative proof-of-work

What SPV cannot verify:

  • That the block is actually valid (could contain invalid transactions)
  • That the chain is canonical (if eclipsed, attacker feeds fake chain)
  • That a transaction has NOT been included (omission attacks)

Block Headers Over Mesh

Block headers (80 bytes, or Archipelago's compact 44-byte format) allow:

  • Tracking chain tip (current block height)
  • Detecting stale/fake data (blocks should arrive ~every 10 min)
  • Verifying proof-of-work continuity

Headers alone are NOT sufficient for SPV verification. You also need Merkle proofs (~320-384 bytes per transaction) to verify inclusion. This fits within Archipelago's Reed-Solomon chunking.

Compact Block Filters (BIP157/158)

~15KB per block — too large for LoRa. But the relay node can run a full node, do filter matching locally, and relay only relevant Merkle proofs back.

Eclipse Attacks

If a mesh node gets headers from only one relay, that relay can feed fake headers. Mining one fake block costs ~$300K-500K at current difficulty — impractical for small amounts, relevant for high value.

Archipelago Status

BlockHeaderCache stores headers by height and tracks latest height. BlockHeaderPayload includes height, hash, prev_hash, timestamp, and announced_by. The announced_by field enables multi-relay comparison.

Gaps

  • No chain continuity validation (prev_hash linkage)
  • No proof-of-work validation on received headers
  • No multi-relay header comparison
  • No Merkle proof relay for transaction inclusion verification
  • No timestamp sanity checking

4. Double-Spend Attacks in Off-Grid Context

This is the most dangerous attack category for off-grid Bitcoin.

Attack Scenarios

Scenario Severity Trustless Fix
Split-path: mesh TX-A + internet TX-B (sender sends conflicting txs on two channels) Critical None — wait for confirmations
RBF attack: sender replaces mesh TX via internet with higher-fee conflicting tx Critical Detect RBF signaling (nSequence), reject/warn
Time-delay: relay holds TX while sender broadcasts conflicting tx via internet High Multiple relays, monitor for confirmation

Confirmation Safety Levels

Confirmations Time Security Level Off-Grid Recommendation
0 (mempool) Immediate Zero — trivially reversible Never accept for any value
1 ~10 min Low — rare reorg can reverse Minimum for small amounts
2 ~20 min Medium — very unlikely reversed Good for moderate amounts
3 ~30 min High — practically irreversible Recommended for meaningful amounts
6 ~60 min Very high — requires 51% attack Required for high value

Archipelago Status

TxConfirmation (type 12) tracks 1, 2, 3 confirmations and block_height — correct approach.

Gap: RBF Detection

Recommendation: Check nSequence on relayed transactions. If it signals RBF (nSequence < 0xFFFFFFFE), warn the sender or reject the relay in off-grid context.

5. Balance Checking — Risks and Considerations

On its own, knowing a balance is low severity — all Bitcoin balances are public on-chain. However, in a mesh context, the concern shifts to metadata:

Risk Severity Description
Privacy leak via mesh Medium If balance queries are unencrypted, mesh listeners learn which addresses a node controls
Targeted robbery ("$5 wrench attack") High Knowing a nearby mesh user holds significant BTC creates physical safety risk
Double-spend calibration Medium Attacker learns victim's UTXO set, can craft better conflicting transactions
Change address correlation Medium Balance checks reveal which outputs belong to the same wallet

Mitigations

  • All balance queries must be E2E encrypted (Archipelago already does this)
  • The relay should not learn which addresses are being queried (use compact block filters or xpub-blind queries)
  • Consider running balance checks against the local pruned node rather than relaying
  • Never display exact balances in mesh message logs
  • Watch-only wallet approach: node only has xpubs, so even if compromised, no funds can be stolen

Is Balance Info Useful to an Attacker?

Not fundamentally — the same data is publicly available on any block explorer. The real risk is correlating an address/balance to a physical location via mesh radio proximity. The mesh signal reveals "someone nearby controls this wallet." That's the threat, not the balance data itself.

6. Relay/Intermediary Attacks

Man-in-the-Middle

  • Without encryption: MITM can read, modify, replay everything. Critical.
  • With Archipelago's encryption: Messages use ChaCha20-Poly1305 with X25519 key agreement. MITM cannot decrypt or modify. Reduced to traffic analysis.

Address Substitution

If the relay constructs the unsigned PSBT → Critical (relay can substitute address). If the sender signs locally and sends signed tx → Safe (signature prevents modification).

Archipelago's TxRelayPayload contains tx_hex (fully signed) — correct. Relay cannot modify.

Replay Attacks

Bitcoin transactions are inherently idempotent — replaying a signed tx is harmless (network rejects duplicates). For non-transaction messages, the TypedEnvelope includes a ts timestamp for replay window rejection. The Double Ratchet provides per-message keys with forward secrecy, inherently preventing replay.

Sybil Attacks

Attacker runs multiple mesh nodes to surround a target (mesh eclipse attack).

  • Severity: High — enables censorship, fake headers, selective relay
  • Mitigation: Pre-configured trusted peer list (known Ed25519 public keys via DID)

Single Malicious Relay

If your only relay to the internet is malicious:

  • Can censor transactions
  • Can feed fake block headers (within PoW cost constraints)
  • Can claim broadcasts happened when they didn't
  • Cannot steal funds, modify transactions, or extract keys

Same trust model as running a Bitcoin node behind a single ISP.

7. Lightning Network Off-Grid Considerations

Can Lightning Work Over Mesh?

Partially, with severe constraints:

  • Invoice generation: Works offline (just needs keys + channel state). BOLT11 relayed via mesh.
  • Payment routing: Requires the paying node to be online. Mesh-only node cannot route.
  • Relay model: Mesh node generates invoice → sends via mesh → internet peer pays with its own LND. Requires trust in relay.

Channel State Attacks

Critical risk for off-grid LN nodes. If your node goes offline:

  • Channel partner can broadcast revoked (outdated) commitment transaction
  • They have the CSV delay (~24 hours) to steal funds before you can respond
  • If offline longer than CSV delay, funds can be stolen

Watchtower Requirements

Mandatory for any off-grid LN node:

  • Must be internet-connected and always online
  • Needs encrypted breach remedy data (provided in advance)
  • Does NOT need private keys — only pre-signed penalty transactions
  • LND has built-in watchtower client/server

HTLC Timeout Risks

Lightning HTLCs use absolute timelocks. Over high-latency mesh:

  • Invoice relay takes minutes to hours
  • HTLC might expire before payment completes
  • Locked funds until timeout resolution

Recommendations

  • Close or minimize Lightning channels before going off-grid
  • Use watchtowers (configure before going offline)
  • Set long CSV delays (1008 blocks / ~7 days) for off-grid risk channels
  • Validate BOLT11 invoice expiry before relay payment (reject if <10 min remaining)

Archipelago Status

LightningRelayPayload includes bolt11 and amount_sats. LightningRelayResponsePayload returns payment_hash and preimage (cryptographic proof of payment). The preimage is sufficient proof.

Gap: Invoice Expiry Validation

Recommendation: Relay should validate BOLT11 invoice expiry before attempting payment. Reject if about to expire.

8. Trusted vs. Trustless Solutions

Solution Trust Level Off-Grid Fit Best For Bandwidth
On-chain + confirmations Trustless Good (with relay) High value, can wait ~250-500 bytes/tx
Fedimint ecash Federation (3-of-5) Excellent Community payments ~200 bytes/token
Cashu ecash Single mint Excellent Small amounts, fast ~200 bytes/token
Multisig escrow (2-of-3) Arbiter Good with PSBT High-value trades ~500 bytes/PSBT
Lightning relay Relay trust Partial Fast small payments ~500 bytes/invoice

Fedimint (Federated Chaumian Ecash)

  • Federation issues ecash tokens backed by Bitcoin in multisig
  • Tokens are bearer instruments — transferable offline
  • Double-spend prevention requires online redemption with the mint
  • Federation can be local (mesh-connected nodes)
  • Trust: threshold of guardians (e.g., 3-of-5) must not collude

Cashu (Single-Mint Ecash)

  • Simpler than Fedimint, single mint operator
  • Same bearer token model, transferable offline
  • Higher trust (single operator) but simpler deployment
  • Ideal for low-value, fast mesh transactions

Multisig Escrow

For high-value off-grid trades:

  1. Pre-establish 2-of-3 multisig (buyer, seller, arbiter)
  2. Buyer funds before going off-grid
  3. Both parties sign via PSBT over mesh upon delivery
  4. Arbiter resolves disputes later

Post-Taproot: MuSig2 key path spend looks like single-sig on-chain (privacy).

OpenTimestamps

Compact proofs (~few hundred bytes) that data existed at a specific time, anchored to Bitcoin blocks. Useful for unforgeable receipts of payment intent.

9. Cryptographic Protections

Current Archipelago Implementation (Strong)

Layer Implementation Assessment
Key agreement X25519 ECDH (Ed25519 → X25519 conversion) Production-grade
Encryption ChaCha20-Poly1305, random 12-byte nonce from OsRng Correct choice for constrained environments
Forward secrecy Double Ratchet protocol Per-message keys, post-compromise security
Key derivation HKDF-SHA256 Standard
Zeroization zeroize crate on ratchet key material Good
Signing Ed25519 via TypedEnvelope::new_signed() Correct
RNG OsRng (CSPRNG) throughout Correct — never rand::thread_rng()

Gap: Dead Man Switch Encryption

The DeadManSwitch alert includes GPS coordinates. If broadcast on channel 0, any mesh listener can read the location.

Recommendation: Encrypt dead man alerts to each emergency contact individually (using their public keys), not cleartext broadcast.

Gap: Payment Intent Message Type

Recommendation: Create a signed "payment intent" envelope (destination, amount, timestamp, sender signature). Non-repudiable record for dispute resolution.

10. Real-World Precedents

Blockstream Satellite

  • Model: Receive-only blockchain data from geostationary satellites
  • Trust: Minimal — receiving node validates proof-of-work
  • Limitation: Receive-only; needs separate return channel for broadcasting
  • Relevance: Complementary receive channel. Archipelago node could receive blocks from satellite (high bandwidth) and send transactions via mesh (low bandwidth).

goTenna + Samourai Wallet (TxTenna)

  • Model: Signed transactions broadcast via goTenna mesh (UHF, ~1-2km)
  • Trust: Relay chain untrusted — can only forward or drop, not modify
  • Security gap: No confirmation feedback. No proof of broadcast.
  • Relevance: Archipelago's design is strictly superior — bidirectional relay, block headers, E2E encryption. TxTenna had none of these.

Locha Mesh

  • Model: Custom LoRa hardware for Bitcoin + Lightning in Venezuela
  • Innovation: Combined Blockstream Satellite (blocks) + mesh (transactions)
  • Status: Development stalled (~2021)
  • Relevance: Hybrid satellite + mesh is the ideal model.

Machankura (USSD Bitcoin in Africa)

  • Model: Fully custodial Lightning via USSD dial codes on feature phones
  • Trust: Complete — they hold all keys
  • Relevance: Demonstrates custodial models have product-market fit in connectivity-constrained environments. Archipelago is the self-sovereign middle ground.

11. Mesh-Specific Attack Vectors

Attack Severity Detection Mitigation
Continuous radio jamming High RSSI spike, no valid packets Frequency hopping, directional antennas, relocation
Selective/reactive jamming Critical Hard — packets just "fail" LoRa spread spectrum helps, but SDR can selectively jam
Selective relay High Timeout on expected responses Multiple relay paths, RelayTracker timeouts
Timing analysis (mesh → mempool correlation) High — Random broadcast delay jitter, steganography
Physical proximity (LoRa = geographically nearby) High — Higher SF for range, multi-hop, low TX power
Sybil (fake nodes surrounding target) High Unknown peers appearing Pre-configured trusted peer list (Ed25519/DID)
Fake GPS/time attacks Medium Clock drift detection Use block height not timestamps, cross-reference headers

12. Summary: Archipelago Strengths and Gaps

Already Strong

  • E2E encryption (ChaCha20-Poly1305 + X25519)
  • Forward secrecy (Double Ratchet)
  • Signed message envelopes (Ed25519)
  • Transaction relay with response tracking (RelayTracker)
  • Block header relay (BlockHeaderCache)
  • Confirmation tracking (TxConfirmation type 12)
  • Dead man's switch with GPS
  • Steganographic encoding for plausible deniability
  • CSPRNG throughout (OsRng), sats as u64
  • Reed-Solomon chunking for large payloads over LoRa

Priority Gaps

# Gap Severity Effort Category
G1 Validate block header chain continuity (check prev_hash linkage) High Low Verification
G2 Validate proof-of-work on received headers High Medium Verification
G3 Sign TxRelayResponse with relay Ed25519 key Medium Low Authentication
G4 Encrypt dead man alerts to emergency contacts (not cleartext) High Medium Privacy
G5 RBF detection — warn/reject RBF-signaled mesh txs High Low Double-spend
G6 BOLT11 invoice expiry validation before relay payment Medium Low Lightning
G7 Multi-relay header comparison (detect eclipse) High Medium Verification
G8 Merkle proof relay for SPV transaction inclusion High Medium Verification
G9 Timestamp sanity checking on received headers Medium Low Verification
G10 Payment intent message type (signed, non-repudiable) Low Low Authentication
G11 Random broadcast delay jitter (timing analysis resistance) Medium Low Privacy
G12 Consider Cashu/ecash for small off-grid payments Medium High Trust model
G13 Watch-only wallet architecture (no keys on node) High Medium Key security

References