Here’s the crack in the wall — and to be clear, this is my own speculative engineering, not an existing protocol, so treat it as a design sketch rather than something you can deploy.
Private keys can be split additively. Instead of one person holding the full secret x, split it: x = x_A + x_B, where the isolated person memorizes or hides x_A (small enough to recall, or written as a number), and a remote helper — reachable by phone — holds x_B. Neither knows the full key. The public address is computed once, jointly, by borrowed computation.
At spending time, threshold signing schemes let the two parties cooperate to produce a signature of x without ever combining the secrets. The division of labor in such a protocol:
The helper (remote computer) does everything heavy: hashing, all elliptic curve point multiplications, network communication, transaction construction.
The isolated person ends up needing to do only a small number of big-number modular multiplications per transaction — things like computing H · x_A mod ℓ. That’s not trivial! One careful 77-digit-by-77-digit multiplication with reduction is an hour-plus of paper arithmetic, triple-checked. But it’s hours per transaction, not months — this is the difference between “possible” and “impossible,” crossed.
All the person’s inputs and outputs fit comfortably over a telephone: the helper reads them a challenge value (~64 hex digits), they do their arithmetic, and read back their partial contribution (~64 digits). Signatures and addresses are small enough that dictation, repetition-back, and reading-it-twice gives you practical error control — humans cross-checking spoken hex is a solved problem in aviation and medicine.
Where the security model degrades
Even in a perfect two-party protocol, the helper holds dangerous influence:
They can’t steal the funds — forging a signature requires the person’s share. That property survives even if the helper is malicious.
But they can lie about what you’re signing. The person can’t independently verify the blockchain state, their balance, or the transaction the helper constructed. A dishonest helper could present a transaction that appears to pay $50 but actually drains the wallet to an address they control (the victim would have to verify the destination address by reading 95 Base58 characters aloud — fatiguing and error-prone).
They can censor or extort — refuse to cooperate until paid, since cooperation is required for every spend.
Classic mitigations apply: use two independent helpers with a 2-of-3 style setup so no single one is a chokepoint, or a “watchman” arrangement where each helper audits the other. But there’s a residual cost: the person must trust someone else’s report of what the blockchain says, whereas a fully-equipped Monero user trusts mathematics alone.
Notes on the other obvious approaches
Hash-based signatures (Lamport-style) replace curve math with many hash computations — tempting because hand-hashing is “easier” per operation, but a single signature needs hundreds of hashes, each taking a skilled human close to a day. Days of unverified hand-hashing per spend trades one infeasibility for another.
The already-existing real-world analog is air-gapped hardware wallets, which solve “offline signer with minimal human computation” — they just assume possession of a tiny computer. Your question is essentially “can a human be the cold-card?” and the threshold-sharing answer above is the closest yes.
Two honest caveats to all of this. First, nothing like this exists as deployed, tested software — building it correctly (blinding the partial signatures so the helper learns nothing across sessions, replay protection over a voice channel, mutual authentication of the helpers) is serious cryptographic engineering where mistakes leak keys silently. Second, on the practical side: if the isolation setting is an institution like a prison, holding and moving funds through arrangements like this may violate that institution’s rules regardless of the cryptography’s elegance — something anyone in that situation should weigh before relying on it.
The setup (done once, face-to-face or via trusted courier)
The two people establish what I’ll call a pad book — essentially a one-time pad expressed in words, sized for their expected correspondence:
~200 numbered entries. Each entry is a random-looking 8-digit number or two random dictionary words (randomness from dice, of course — our running theme). Entries are numbered 1 to 200 in advance.
Each page/entry also has space for a strike-through: once used, it’s crossed out permanently. One-time use is the whole security engine.
They agree on verbal conventions up front: words from the Monero wordlist spelled aloud letter-by-letter when precision matters, digits read in pairs (“forty-seven, twelve…”), and a mandatory read-back rule — the listener repeats everything back, character group by group.
The pad book is small enough to memorize progressively, hide, or reconstruct from memory. That’s important for someone who can be searched.
The handshake: proving you’re you
Every call opens with mutual challenge-response that consumes two pad entries:
Caller states their identity word and the pad entry number they’re drawing on, say #47.
The receiver picks a challenge that must be unpredictable: the last four digits of the current date plus a number of their own choosing, spoken fresh. Pre-recording doesn’t help the impersonator because they can’t anticipate the challenge.
Caller responds with entry #47 of their pad book, modified by the challenge — e.g., add the challenge digits to entry #47 digit-wise mod 10, and speak the result.
Roles reverse: the receiver proves themselves the same way with a different entry.
This is a genuine zero-knowledge-flavored proof of possession: an eavesdropper who records the call learns #47-plus-that-challenge, which is useless next call because a fresh entry and fresh challenge are used. Impersonating requires the pad book itself.
Detecting tampered messages: binding the content
Now the harder problem — the caller dictates “send 0.5 XMR to address ABC…” and the helper must know the message arrived intact. Human-computable integrity looks like this:
After dictating the message, the caller computes a checksum fused with a fresh pad entry: take the message’s digits and letters, convert to numbers by an agreed scheme (letters to their alphabet positions, address characters to their Base58 values), add them digit-wise, then add a fresh, unused pad entry on top, mod 10, and speak the resulting ~8 digits as the “message seal.”
The receiver recomputes the message-side sum from what they heard, and checks the seal is consistent. Any altered digit — a changed amount, a transcribed character of the address — shifts the sum and breaks the seal.
Note what this deliberately sacrifices: unlike a cryptographic hash, this scheme can’t stop a clever adversary from making compensating changes. It shines against its real enemies — human transcription fatigue, phone-line errors, and a lazy intermediary who edits a figure hoping you won’t notice. Against a sophisticated active attacker it’s a speed bump. Honesty requires saying that plainly.
Anti-replay and anti-fabrication
Because every seal burns a pad entry and entries are struck through after use, an old message can’t be replayed — the seal references an entry number already crossed out, which the receiver treats as an alarm, not an oversight. Wrong entry number, reused entry, or a seal that fails three read-backs means: stop, say nothing else, hang up. One scripted abort phrase, agreed in advance, keeps an attack from turning confusion into leakage.
What this buys, and what it can’t
It genuinely delivers: impostor detection (both directions), practical tamper-evidence against casual alteration, replay protection, and error correction through disciplined read-backs — all computable by one tired human with a pocket pad book.
It cannot deliver: protection against an adversary who captures the pad book, forward secrecy (if the book is later seized, all recorded past calls become forgeable in the sense that the seals no longer prove anything — the data itself was never encrypted anyway), or any real confidentiality — the message content travels in the clear by design, protected only by obscurity of the address, which is fine here since Monero amounts and addresses aren’t secrets the way keys are.
And the human factor is the dominant risk by far: the protocol’s security reduces to whether two people reliably strike through used entries and refuse to improvise under social pressure. A smooth-talking caller saying “we ran out of pad entries, just use my birthdate” defeats everything — so the cardinal rule is that no verbal excuse ever replaces a valid seal.
Tying it back to the threshold-signature sketch: this voice layer is how the isolated person would receive the challenge values from the helper, transact their one big modular multiplication, and return their partial signature with a seal proving it wasn’t mangled in transit — the pad book effectively becomes their “network interface.”