archy/docs/mesh-bitcoin.md

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

• PSBT Security Best Practices — CertiK
• BIP174: Partially Signed Bitcoin Transactions
• Transaction Relay — Bitcoin Core Academy
• SPV — Electrum Documentation
• BIP158: Compact Block Filters for Light Clients
• Eclipse Attacks on Bitcoin's P2P Network
• Replace by Fee — Bitcoin Wiki
• Irreversible Transactions — Bitcoin Wiki
• Time-Dilation Attacks on the Lightning Network
• Watchtowers — Lightning Builder's Guide
• TxTenna — GitHub
• Blockstream Satellite
• Locha Mesh — GitHub
• Machankura FAQ
• Fedimint
• Cashu — Open-source Ecash
• OpenTimestamps
• LoRaWAN Physical Layer Attacks