Boomerang: Bitcoin Cold Storage with Built-In Coercion Resistance

[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.

[drangos]

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.

I concur that this makes Boomerang more appropriate among users with serious threat model and not among daily users. The fact that the range of steps is selectable and that the delay is random causes significant duress resistance, yet produces randomness and slowness in access to funds. The minimum and maximum window is useful in planning, but errors in setups might be very expensive. To the majority of users, multisig or timelocks might be easier to use in general.

[bitryonix]

I concur that this makes Boomerang more appropriate among users with serious threat model and not among daily users. The fact that the range of steps is selectable and that the delay is random causes significant duress resistance, yet produces randomness and slowness in access to funds. The minimum and maximum window is useful in planning, but errors in setups might be very expensive. To the majority of users, multisig or timelocks might be easier to use in general.

Drangos you are absolutely right here. This design is not viable for a common individual and is targeting a niche segment.

Nevertheless, we see this as a first attempt to integrate duress protection in a systematic way into the conventional structures with plausible deniability against an informed attacker (no security through obscurity).

It is true that a common user cannot afford the uncertainty in Boomerang. During design we tried to implement back channels to alleviate this issue to some degree. But all of them added to the attack surface in an unacceptable manner and some of them required another third party. This did not sit well with our extreme threat assumptions.

But we may make those compromises in a tiered model in which you can seamlessly use a continuum of security levels. In such a system we hope Boomerang can act as a last resort and the final fallback.

Your point on errors in setup is also valid. We are addressing this in two ways currently. First, I am creating a formal proof of the protocol in Tamarin, and second we are going to design ancillaries for the protocol. Ancillaries handle failures, errors, corrections, checks and rotations in the processes and make ceremonies less costly should a mistake happen.

Thank you for your feedback.

[bitryonix]

Hi all. Here I have tried to present a high level overview of the protocol without getting too technical or detailed. It is highly appreciated if you could give me some feedback on the clarity of the text and the merit of the core idea. Thank you all very much.

What is Boomerang?
Imagine you have a lot of bitcoins - maybe for a company or personal savings - and you're worried not just about hackers, but about real-world threats like someone kidnapping you or threatening you to hand over the money. Regular "cold storage" (like keeping your keys offline on a hardware wallet) is great against online thieves, but it doesn't help if an attacker forces you to sign a transaction right away. That's where Boomerang comes in: it's a system designed to make stealing bitcoins through force way harder and riskier for bad guys.

Why Does Boomerang Exist?

• The Problem: Big bitcoin holders (like businesses with millions in bitcoin) often have a few key people who control the ultimate access. Hackers can't easily get in, but a "wrench attack" - basically, physically forcing those people to transfer the money - works because normal systems let you send funds quickly and reliably.
  
• The Goal: Boomerang flips the script. It turns the withdrawal process into something unpredictable in timing during a certain period, with built-in ways to securely signal duress. Attackers can't count on getting the money in a set timeframe (or without risks), so they're less likely to try. Importantly, you can always withdraw eventually if everything's legit. It's just not instant or predictable at first, and becomes straightforward after a set time.
  

It's like hiding your treasure in a vault that takes a random, unknown, but within a wide range (selected by you privately), amount of time to open, and you can secretly hit a panic button without the attacker detecting if you have done such thing during the process. After a milestone (like 2 years), the vault can be opened normally and deterministically.

How Does It Work?
Boomerang isn't for everyday spending. It's for long-term storage where you rarely need to touch the funds. Here's the basics:

• Setup Basics:
  
  • You split control among a small group (e.g., 5 trusted people or "peers").
  • Each person uses special hardware devices (like secure cards or apps) to hold parts of the keys.
  • You also connect to neutral "watchtowers" (services that help coordinate) and "search and rescue services" (that can alert help if things go wrong).
  • You provide encrypted personal info (like your location) to the rescue service, locked with a secret password only you know.
  • Each peer privately sets their own range for how many "steps" (rounds of checks) their part of the process might take; say, a minimum and maximum number, like 6 months to 1 year worth of steps (tied to Bitcoin's blockchain timing). The group doesn't share these ranges; each person's device (Boomlet) randomly picks a number within their own private range when needed.
  • The group agrees on a future "milestone block 1" (a specific point on the Bitcoin blockchain, e.g., in 2 years) after which withdrawals become fast and predictable; no more randomness.
  • Prior to the milestone, the withdrawal is non-deterministic and the duress protection is in place. After that milestone, it is just a plain normal spending condition in a taproot address.
  
  
• Withdrawing Money:
  
  • To move bitcoins, everyone in the group has to approve through a back-and-forth process.
  • In the boomerang period (before the milestone mentioned earlier, like the first 2 years), it involves multiple rounds of checks (the "digging game"). The exact number of steps for each peer's part is randomly picked by their Boomlet within their own private min-max range. No one (not even the group) knows the others' ranges or picks upfront, creating overall uncertainty in total time - so neither do attackers. This makes it hard for bad guys to plan around the timing, giving potential victims time (e.g., months) to be rescued if coerced.
  • During approvals, you can secretly signal "I'm under duress" (e.g., by choosing certain options in a quiz-like interface on a device). This looks normal to attackers but triggers the rescue service.
  • If anything seems off (like missed duress checks or messed up responses), the process just... stops. No money moves. But if all's good, it completes - you just don't know exactly how long it'll take ahead of time.
  • After the milestone block (e.g., 2 years in), you enter a "normal era" where everything is quick and deterministic, like regular cold storage.
  
  
• Duress Protection:
  
  • The "secret signal" is easy: You memorize a set of 5 countries during setup as the consent set. Later, the system shows lists of countries, and your choices either confirm "all good" by entering the consent set or scream "help!" by entering any other combination of countries without obvious signs or stopping the ceremony. You signal the duress but the attacker observe no change compared to the non-duress situation.
  • If duress is signaled, the rescue service gets your info and can start a "search and rescue" - like contacting authorities or trusted contacts.

The whole thing uses encryption and anonymous networks (like Tor) to keep communications hidden. It's not foolproof against everything, but it makes coercion a bad bet for attackers: too uncertain in duration and too risky.

Who Is It For?

• Big Holders: Companies or wealthy individuals with bitcoin they don't need to access often (e.g., long-term reserves).
  
• High-Risk Situations: Places where physical threats are real, like in unstable regions.
  
• Not For: Casual users or quick trades; it's too slow and complicated for that.
  

In short, Boomerang is like a bitcoin safe with a randomized time-delay lock and a hidden alarm during the boomerang phase, switching to normal access after a milestone. It prioritizes ultimate protection over convenience, making it tougher for anyone to force you out of your bitcoin. If you're curious about setting it up or the costs, it involves hardware, fees for services, and coordinating with others.