# 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](https://www.certik.com/resources/blog/exploring-psbt-in-bitcoin-defi-security-best-practices)
- [BIP174: Partially Signed Bitcoin Transactions](https://bips.dev/174/)
- [Transaction Relay — Bitcoin Core Academy](https://bitcoincore.academy/transaction-relay.html)
- [SPV — Electrum Documentation](https://electrum.readthedocs.io/en/latest/spv.html)
- [BIP158: Compact Block Filters for Light Clients](https://bips.dev/158/)
- [Eclipse Attacks on Bitcoin's P2P Network](https://eprint.iacr.org/2015/263.pdf)
- [Replace by Fee — Bitcoin Wiki](https://en.bitcoin.it/wiki/Replace_by_fee)
- [Irreversible Transactions — Bitcoin Wiki](https://en.bitcoin.it/wiki/Irreversible_Transactions)
- [Time-Dilation Attacks on the Lightning Network](https://arxiv.org/pdf/2006.01418)
- [Watchtowers — Lightning Builder's Guide](https://docs.lightning.engineering/the-lightning-network/payment-channels/watchtowers)
- [TxTenna — GitHub](https://github.com/MuleTools/txTenna)
- [Blockstream Satellite](https://blockstream.com/satellite/)
- [Locha Mesh — GitHub](https://github.com/btcven/locha)
- [Machankura FAQ](https://8333.mobi/faqs)
- [Fedimint](https://fedimint.org/)
- [Cashu — Open-source Ecash](https://cashu.space/)
- [OpenTimestamps](https://opentimestamps.org/)
- [LoRaWAN Physical Layer Attacks](https://pmc.ncbi.nlm.nih.gov/articles/PMC9100101/)