Boomerang: Bitcoin Cold Storage with Built-In Duress Protection

[bitryonix]

Hello everyone,

I’d like to share a new Bitcoin custody protocol designed to significantly improve physical security and coercion resistance for high-value holders.

Boomerang is a Bitcoin cold storage protocol with integrated duress protection. It lets you set up custody such that withdrawals become intentionally non-deterministic and include duress signaling, without requiring any changes to Bitcoin consensus. This creates uncertainty for attackers and gives holders a better chance to survive coercion attempts.  

Key features at a glance

• Protocol-level duress protection built into the custody process.  
• Non-deterministic withdrawal ceremony to reduce predictability.
• Fully compatible with Bitcoin consensus.  
• Proof-of-concept implementation in Rust.

Protocol Description
Boomerang is a Bitcoin cold-storage protocol designed for high-value holdings, providing strong protection against duress (e.g., coercion or threats) without altering Bitcoin's consensus rules. It achieves this through a non-deterministic withdrawal process enforced by secure hardware, creating unpredictability in signing with embedded, plausibly deniable duress signaling and optional "search-and-rescue" (SAR) escalation. Funds are locked in a Taproot output with two spending regimes: a probabilistic "Boomerang" path using MuSig2 keys (including a non-backupable key in a Java Card applet) requiring 5-of-5 multisig, and a deterministic "normal" path with timelocks for fallback.

Setup
The setup involves coordinated, secure steps among entities like the user, isolated environments (Iso), secure terminals (ST), watchtowers (WT), SAR providers, and hardware applets (Boomlet/Boomletwo):

• SAR Registration: User registers with SAR entities via an encrypted phone app, providing doxing data for potential rescue.
• Key Generation: In an air-gapped Iso, generate a normal mnemonic key and Boomlet applet creates MuSig2 shares plus a non-backupable boomlet key. Set duress consent via selecting 5 countries (exact match signals no duress).
• Parameter Agreement: Peers agree on timelocks (milestone blocks), and WTs via encrypted, signed TOR exchanges.
• Mystery Generation: Each Boomlet randomly selects a secret "mystery" threshold (steps in withdrawal) within a user-defined range.
• Backup and Sync: Create/verify a single backup applet (Boomletwo); synchronize keys, parameters, and fingerprints via WT for consistency.

This ensures no single party can predict or bypass the process, emphasizing tamper-evident hardware and opsec.

Withdrawal
Withdrawal is a collaborative, unpredictable multi-phase ceremony post-milestone_block_0, involving all 5 peers signing a PSBT:

• Initiation: One peer creates and shares the PSBT; all approve via ST and WT.
• Duress Check: Each peer selects countries; mismatches signal duress, triggering encrypted SAR payloads without altering behavior.
• Digging Game: A ping-pong loop of signed messages via WT, incrementing a counter until each Boomlet hits its secret mystery threshold (could take months due to randomness). Pseudo-random duress checks occur throughout.
• Signing: Generate/aggregate MuSig2 partial signatures offline in Iso; broadcast via WT.
• Fallback: If stuck (e.g., lost hardware), funds unlock deterministically after timelocks via normal keys.

The design prioritizes coercion resistance through unpredictability and deniability.

Repositories

• Design and specification of the protocol: https://github.com/bitryonix/boomerang_design
• Proof-of-concept Rust implementation following the design: https://github.com/bitryonix/boomerang

I’m looking forward to your critical reviews, feedbacks and collaborations, especially around security analysis, usability improvements, and real-world deployment guidance.

Here is our email: bitryonix@proton.me

Thanks,
bitryonix

[Vod]

Hi bitryonix,

Interesting idea.   Can you explain in layman's terms how your protocol can fool an attacker into thinking he has received irreversible bitcoin?

[Pmalek]

If I understand it correctly, Boomerang would allow me to send duress signals to previously approved third parties, informing them that I am in danger. The third party would then, after seeing the signal, act according to what we agreed they would do if they receive such signals. They could call the police, come to me to help, etc.

An attacker wouldn't be able to notice any of this. It looks like I am complying, but there is a delay or something is not working properly.

How are those duress signals sent and what do they look like on the device of my trusted third party?

[bitryonix]

Hi bitryonix,

Interesting idea.   Can you explain in layman's terms how your protocol can fool an attacker into thinking he has received irreversible bitcoin?

Hey Vod,

Boomerang does not convince the attackers that they have received bitcoin. It makes the process of signing non-deterministic and puts duress checks in the process.

The user knows an upper and lower limit of number of blocks that should pass for the transaction to be signed. But neither the user nor the attacker knows exactly how long should they wait for the transaction to be signed, 1 week? 3 months?. Hence, the attacker cannot easily mobilize resources to capture and coerce.

On the other hand, a common attacker cannot determine if a duress signal has been sent in the process or not. And signing cannot happen without duress checks.

All these can deter an attacker in the first place.

I should mention that the current design works best for large, long-term holdings. But we will work on a mini configuration that can be used in retail wallets as well.

Thanks for your question Vod.

[bitryonix]

If I understand it correctly, Boomerang would allow me to send duress signals to previously approved third parties, informing them that I am in danger. The third party would then, after seeing the signal, act according to what we agreed they would do if they receive such signals. They could call the police, come to me to help, etc.

An attacker wouldn't be able to notice any of this. It looks like I am complying, but there is a delay or something is not working properly.

How are those duress signals sent and what do they look like on the device of my trusted third party?

Hey Pmalek,

Actually it looks like you are complying and everything is working exactly as expected.

If you are using Boomerang, everyone knows that you should participate in a so-called digging game that takes time and you don't know exactly how long. Everyone knows that you'll face duress checks in this period and you should answer them or the process stops and we have no withdrawal.

The point here is that the duress checks absolutely do not affect the process except for putting a key in an encrypted payload that is sent along with every message. This duress placeholder or payload should reach that third party (we named it SAR) and it should sign the encrypted payload for the process to move forward, in every back and forth in the digging game. When the duress placeholder is reached to SAR, and only if you sent a positive duress signal, it can use that placeholder to decrypt your doxing data.

Thanks for your question Pmalek.

[Pmalek]

If you are using Boomerang, everyone knows that you should participate in a so-called digging game that takes time and you don't know exactly how long. Everyone knows that you'll face duress checks in this period and you should answer them or the process stops and we have no withdrawal.

So even if you aren't under duress and no one is physically forcing you to give them your bitcoin, you still don't know how long it will take for a transaction to finally be broadcast due to the way the system is configured. It will take a random amount of time that you can't shorten. Did I understand that part correctly?

[bitryonix]

If you are using Boomerang, everyone knows that you should participate in a so-called digging game that takes time and you don't know exactly how long. Everyone knows that you'll face duress checks in this period and you should answer them or the process stops and we have no withdrawal.

So even if you aren't under duress and no one is physically forcing you to give them your bitcoin, you still don't know how long it will take for a transaction to finally be broadcast due to the way the system is configured. It will take a random amount of time that you can't shorten. Did I understand that part correctly?

Yes. But you know a range that you should yourself select in the setup ceremony, from which a random number of steps is selected. You choose that range based on your judgement considering the required reaction time to duress signal, your expected outflow of funds and the notice period of such outflows. Hence, though you don't exactly know how many steps does the game take, you'll know the minimum and the maximum.

I must emphasize as before, that this design may cover a niche segment with high threat assumptions and is not your regular cold storage.

[Vod]

Yes. But you know a range that you should yourself select in the setup ceremony,

Tell me the range or I start killing people you love. 

If a crypto whale is targeted, the attackers would know of your device and they can work around the limits you sent.  Your device could work if it wasn't an everyday wallet, but instead a time driven process that you cannot complete without input from a trusted third party.

[bitryonix]

Yes. But you know a range that you should yourself select in the setup ceremony,

Tell me the range or I start killing people you love. 

If a crypto whale is targeted, the attackers would know of your device and they can work around the limits you sent.  Your device could work if it wasn't an everyday wallet, but instead a time driven process that you cannot complete without input from a trusted third party.

You are right Vod, and that's exactly what we have done.

At the current design, we have 5 peers, and a watchtower. Each peer has an SAR. And while in boomerang regime (in boomerang regime the keys are MuSig2 of the normal key and a key trapped in a java/smart card) you cannot withdraw without the participation of the all before mentioned entities.

You can tell the range, it does not null the duress protection.

The thing is you should choose the end of your boomerang regime in a way that you can roll over to another boomerang setup (we have not yet found viable solution o extend a setup) in time, given your resources, time preferences and operational constraints, so that you don't get pushed into what we call forced determinism. Here is our thoughts on the issue: https://github.com/bitryonix/boomerang_design/blob/main/security/forced_determinism.md

[Vod]

^^ OK, you have passed beyond the Vod zone... stuff over my head.     It sounds to me (in the simplest form) like you cannot withdraw without multisig.  I'm sure there is more to it, but since I don't regularly announce how rich I am, I use "normal people" safeguards, like hiding a wall safe under my petunias.  A crypto holder will usually not need to carry anything with them allowing access to 100% of their funds. 

[bitryonix]

^^ OK, you have passed beyond the Vod zone... stuff over my head.     It sounds to me (in the simplest form) like you cannot withdraw without multisig.  I'm sure there is more to it, but since I don't regularly announce how rich I am, I use "normal people" safeguards, like hiding a wall safe under my petunias.  A crypto holder will usually not need to carry anything with them allowing access to 100% of their funds. 

Indeed Vod, this is not yet an everyday product. Though we hope it gets to a point that it can even add something to your setup.

[Pmalek]

Tell me the range or I start killing people you love. 

If a crypto whale is targeted, the attackers would know of your device and they can work around the limits you sent.

Not necessarily. Unless they have had personal experience with Boomerang or know how exactly it works. From the way I understood it, there is no recognizable way for attackers to see that you aren't complying with their requests. They can see that you are trying to initiate a normal transaction signing process, but for some reason it's taking too long or doesn't work. This isn't a guarantee that they won't physically harm you, though. It might cause exactly that because they may get angry and think you are playing the fool.

[bitryonix]

Unless they have had personal experience with Boomerang or know how exactly it works.

If they have personal experience with Boomerang or know how exactly it works, they know that due to using Boomerang, the withdrawal ceremony takes a relatively long and unknown time. That is the exact expectation and it is guaranteed.

but for some reason it's taking too long or doesn't work.

If they know Boomerang, they know that taking too long is not faulty behavior or caused by non-cooperation on your side. That's how Boomerang is supposed to work even in normal conditions. Just like a 2-of-3 multisig that needs 2 keys to move funds.

This isn't a guarantee that they won't physically harm you, though. It might cause exactly that because they may get angry and think you are playing the fool.

That is why Boomerang somehow is the opposite of security through obscurity. If you announce you are using Boomerang as an enterprise, your attacker thinks twice before the operation against key holders. But if you are facing a crude attacker, you may gonna have the same destiny as if you had a 2-of-3 multisig and needed to explain your inability to move the funds alone to a person totally unfamiliar with bitcoin.

Hence, we need to educate attackers on Bitcoin and, in this case, Boomerang as well

[bitryonix]

Duress Mechanism in the Boomerang Protocol: Protecting Users Under Coercion

Hey everyone, diving deeper into the Boomerang protocol's security features, here's a detailed breakdown of the duress mechanism. This is a system designed to let users signal distress discreetly during withdrawals, without alerting an attacker. It leverages memorized "consent sets" based on countries, encrypted communications, and integration with Search and Rescue (SAR) entities to trigger help if needed. The goal is to make coercion risky for attackers while maintaining plausible deniability.
I'll cover the core concepts, setup, runtime usage (e.g., during withdrawals), security assumptions, and how it handles adversaries. This is based on the protocol's design docs and diagrams. Please feel free to ask for clarifications!

What is the Duress Mechanism?
The duress system allows users to signal coercion (e.g., being forced to sign a transaction) by entering a non-standard input during "duress checks." These checks happen at key points like committing to a withdrawal or randomly during the process. If duress is signaled, the system silently sends a payload to SARs (trusted rescuers) to decrypt and use "doxing data" (personal info for location/recovery) to initiate a rescue, without changing observable behavior to tip off the attacker.
Key actors:

• User: Creates doxing data and a password; memorizes a "consent set" of 5 countries.
• SAR (Search and Rescue Entity): Holds encrypted doxing data; Once received a payload created after a positive duress signal, can decrypt and act on duress signals.
• Adversary: Can capture/observe the user but can't break crypto or hardware security.

Doxing Data: The Rescue Payload
Doxing data helps SAR locate and rescue the user:

• Static Data: Fixed info like name, ID, addresses, phone numbers, and trusted contacts (encrypted with doxing_key = SHA256(doxing_password)). Sent to SAR during setup.
• Dynamic Data: Real-time feeds (e.g., phone location) encrypted and updated continuously.

On duress, Boomlet (hardware wallet) sends the doxing_key (encrypted for SAR) in message payloads. SAR decrypts, hashes to identify the user, and starts rescue ops.

Core Concepts

• Consent Set: 5 unique countries (no order) chosen by the user during setup. Matching this set means "no duress"; any other combination signals duress.
• Country Mapping: Based on 195 countries (UN-like list) sorted alphabetically (1 = Afghanistan, ..., 195 = Zimbabwe).
• Duress Checks: Boomlet generates 5 random lists of 1-195 numbers; ST (Secure Terminal) maps to countries and displays as columns. User selects one per column.
• Plausible Deniability: Under torture, user can reveal any 5 countries as the "consent set"—attacker can't verify without risking a real duress signal.

Probability of random guess succeeding: ~3.73e-12 (1 in 267 billion), making blind attacks infeasible.

Setup Process
Done via isolated devices (Iso, Boomlet, ST) with QR codes for secure, air-gapped comms:

• Boomlet and ST exchange identity pubkeys via Iso/QR to establish shared ECDH key (AES encryption).
• Boomlet generates random list [1-195], encrypts, sends via Iso/QR to ST.
• ST decrypts, maps to countries (alphabetical), displays list.
• User selects 5 countries via joystick (memorizes names); ST records indices, encrypts, sends back via QR/Iso.
• Boomlet decrypts, extracts numbers as consent_set.
• Confirmation: Boomlet sends 5 new random lists; user re-selects to match consent_set. Mismatch? Retry or restart.

After setup, user only remembers 5 country names; system stores numbers securely.

Runtime Process (e.g., During Withdrawal)
Checks triggered by Boomlet (at commitment or PRNG-based random intervals):

• Boomlet generates 5 random [1-195] lists, encrypts, sends via Niso/QR to ST.
• ST decrypts, maps to country columns, displays on small monitor.
• User selects one country per column via joystick (hidden from observer).
• ST encrypts indices, sends back via QR/Niso to Boomlet.
• Boomlet decrypts, extracts numbers, compares to consent_set:
  
  • Match = No duress: Encrypts all-zeroes payload for SAR.
  • Mismatch = Duress: Encrypts doxing_key for SAR.
• Payload embedded in next withdrawal message to Watchtower (WT).
• WT forwards payload to SAR.
• SAR decrypts:
  
  • All zeroes? Ignore (no duress).
  • Else? Hash to doxing_identifier, search database, decrypt doxing data, start rescue.
  • Malformed? Increment counter; if threshold hit, halt protocol.
• SAR signs/acknowledges back to WT/Boomlet for verification.

Once duress is signaled, all future messages carry it. Persistent alert.

Security Features and Attacker Assumptions
Covers forced transactions or continued signing under compromise. Resistant to:

• Replay attacks (fresh random lists each time).
• Typos (set-based, order-insensitive).
• Observation (ST's small screen + hidden input).

Attacker can:

• Capture/observe user, read plain messages, act as user, destroy hardware.

But cannot:

• Break JavaCard security, crypto, or observe ST input without seeing screen + hands simultaneously.

Consequences: No observable changes on duress (plausible deniability); withdrawal proceeds normally but SAR is alerted.