Catching a double-spend with no network

Send Money BT moves value between two phones over Bluetooth LE, with no server and no network in the loop. That rules out the usual answer to double-spending, which is to ask someone authoritative whether the money has already gone. Offline, there's nobody to ask.

You can't prevent it, so prove it

A device that holds its own balance can always be made to lie about it. Roll back its storage, restore a backup, patch the app, and the same balance can be spent twice to two people who never meet. No protocol running on that device can stop this, because the attacker controls the device.

So the goal changes. Instead of trying to make a double-spend impossible, make it impossible to deny: if someone spends the same money twice, the two payments together should be proof that they did, and that proof should need nothing but the two payments to check.

A chain per sender

Every voucher a sender issues includes the hash of the voucher they issued before it, and the whole thing is signed with the sender's key. A sender's history is a hash chain, and each new payment extends it by one link.

Now try to double-spend. To pay Bob and then pay Carol with the same money, the sender has to reuse a point in their history: two different vouchers that both claim h(v3) as their predecessor. An honest sender never produces two successors to the same voucher. The only way to get two is to spend twice.

What makes the fork a good proof

• Self-verifying. Checking it needs the two vouchers and the sender's public key. No ledger, no server, no connectivity.
• Non-repudiable. Both vouchers carry the sender's signature, and only the sender can make that signature. “Someone else made the second one” doesn't hold up.
• Signed by the offender. The evidence is made by the very act of cheating. Nobody has to watch for fraud as it happens.
• Anyone can check it. A peer, a merchant, or a settlement service can all verify it and reach the same answer.

What it doesn't do

Detection happens after the fact. A fork shows up when the two branches meet, which could be at a later peer or whenever either recipient next syncs. Until then Bob and Carol each hold a voucher that looks valid. A proof is only worth something if something follows from it, so a real deployment still needs a consequence: spending limits while offline, a hold on the offender once the proof surfaces, or both.

That's the trade. You give up preventing the fraud, which can't be done offline anyway. In return you get fraud that always leaves proof behind, signed by the person who did it.