pull down to refresh
Yes you are right. It is indeed for high value, very low velocity bitcoins under high threat. This current design does not suit common retail holdings of bitcoin.
Hey,
You need some peers to provide some sort of geographical diversification and more uncertainty as well as a multisig structure.
Regarding the second paragraph, say you have a multisig.
- Say at the best the keys are distributed between 3 persons (compared to you holding keys in different locations).
- Now, I wanna attack you. I put the gun to your head. You tell me it's a multisig. I say (worst case) give me the descriptor so I can examine your claim.
- You provide that. I say now sign this psbt and then take me to your friends (If I have not identified them before).
- You do as I say and I coerce them to sign as well for I have the gun.
The thing here is that the act of signing is very predictable. I put you under duress and I know the signing flow and that's all.
Now consider using Boomerang.
- You come to me with a gun. I tell you my bitcoins are in a boomerang. You demand proof and I provide the descriptor looking like a boomerang descriptor.
- You force me into calling others and convince them to do as I want or you just capture them and put them under duress as well.
- Now what are you facing? We are all cooperative. But neither you nor us know how much time it takes to sign the transaction of your choice. It may take 6 months or 1 year (note that this is for low velocity reserves or fallbacks and not for day to day expenditure). Added on top of that all of us peers can signal duress during this withdrawal ceremony and you won't know if we have done that. For nothing changes after a positive duress signal whatsoever. Except for the trusted entity knowing we are under duress.
Put yourself in the shoes of an attacker. Would your first choice of victim be those that have a setup that takes uncertain time to withdraw and has undetectable duress signals built in the withdrawal ceremony itself?
@OT and @Signal312 could you please give your idea about this brief? Do you see it as transparent enough for a high level overview to communicate the core idea?
Thank you very much.
What is Boomerang?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?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?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?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.
Guys, thank you for the feedback. It is highly appreciated. We'll try to make our description of Boomerang more straight forward. Thank you again.
That’s a fair concern, and Boomerang isn’t trying to defeat an infinitely patient attacker, because realistically no custody system can.
What it targets is how coercion actually happens in the real world: attackers almost always depend on short, predictable windows where they can force cooperation, get the funds, and leave. Holding someone indefinitely is risky, expensive, and hard to sustain.
Boomerang removes that predictability. Even if an attacker forces cooperation, they can’t know how long the withdrawal will take, and the process includes built-in duress checks that create opportunities to signal trouble. Suddenly the attack stops being a quick, controlled event and turns into an open-ended situation with rising risk for the attacker.
So the goal isn’t to “stall forever.” It’s to make coercion unreliable, costly, and uncertain enough that many real-world attacks become unattractive or collapse before succeeding, while working alongside traditional physical and organizational security.
Maybe using this?
https://github.com/bitryonix/boomerang_design
(Still a WIP for now)
Well when they come to the rescue, you cannot deny that they have came to rescue you and that you must have had something to do with that. Given that you wanna be rescued.
Thanks @bodhi for the question.
- Liveness verification
System liveness is continuously validated by comparing the latest block height reported by peers with the height observed by the watchtower. If the difference falls outside the acceptable tolerance range, the protocol treats the state as unreliable. During the active ping-pong phase, the step is rejected and does not advance progress. If detected before ping-pong begins, the protocol safely falls back and initiates fault attribution to preserve consistency and trust. - Hardware redundancy
All critical hardware components are provisioned with a verified backup during the setup ceremony. This backup is designed to securely replace the primary device if needed, ensuring operational continuity without weakening the protocol’s security guarantees.
Both mechanisms are already accounted for in the roadmap and will be fully specified during the ancillary design and implementation phase, where detailed engineering and operational procedures are finalized. We are not there yet.
My bad @Signal312. Let me put all technicalities aside.
- Imagine an enterprise holding significant Bitcoin reserves. Even with best-practice operational security, ultimate signing authority typically concentrates in a small group, for example, five senior managers controlling core keys.
- That concentration creates a high-value human attack surface. Those individuals become prime targets for coercion attacks such as kidnapping, extortion, or physical threats, so-called “wrench attacks.”
- A critical but often overlooked assumption behind coercion attacks is predictability. The attacker expects a clear, bounded path to success: force the key holders to sign a transaction and receive funds within a known timeframe. Traditional signing is deterministic; once coerced, the outcome is immediate.
- Boomerang breaks this predictability. Signing is intentionally non-deterministic. Each signing key is a MuSig2 aggregate of two components: a conventional key and a hardware-sealed key embedded in a secure device. The sealed key is non-extractable and will only participate in signing after a multi-party verification protocol of unpredictable duration completes.
- During this protocol, all key holders must repeatedly confirm transaction intent and indicate whether they are acting under duress. Independent external verifiers confirm system integrity and ensure duress signals are properly transmitted and acknowledged. If any required confirmation fails, signing halts.
- Neither the key holders nor an attacker can determine exactly how long the withdrawal process will take. The delay is bounded but intentionally uncertain. Crucially, duress signaling is indistinguishable from normal protocol traffic to an attacker, and withholding responses prevents completion.
- The practical effect is that a coerced withdrawal becomes unreliable, slow, and risky from the attacker’s perspective, potentially taking weeks or months, undermining the core incentive behind coercion.
- Boomerang is not intended for everyday liquidity operations. It is designed as a strategic cold-storage layer for extreme threat scenarios; a defensive fallback when compromise, intrusion, or coercion risk is suspected.
- It is particularly well suited for low-velocity reserves: funds that do not require rapid access but demand maximum protection against physical or social attacks.
Note: The full protocol includes additional safeguards and edge-case handling not covered in this high-level overview.
I hope this helps.
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 "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.
Entities
- User / Peers: 5 entities that collaborate as the main key holders of the protocol. We name the peer from whose POV we explain the protocol, the user.
- Iso: A stateless piece of software that is run on an isolated computing environment.
- Niso: A stateful piece of software that runs on a non-isolated computing environment with access to a full bitcoin node and TOR network.
- Boomlet: A java card applet that is installed and run on a java card.
- Boomletwo: A java card applet that is installed and run on a java card, acting as the back up of Boomlet.
- ST: Short for Secure Terminal. A tamper evident, air-gapped hardware used for trust minimization in communications between user and boomlet.
- WT: Short for Watchtower. An online entity that manages coordination of the peers and act as one of the roots of trust to provide the heartbeat of the protocol which is the latest bitcoin block height.
- SAR: Short for Search And Rescue. Is an online entity that receives encrypted doxing data from user and checks for the duress signal. Should it detect a positive duress signal, the SAR uses that signal to decrypt the doxing data and perform a search and rescue operation based on the aforementioned data. Since SAR's operations are mostly focused on physical security, this entity is jurisdiction dependent in order to comply with the pertinent use-of-force rules and regulations.
- Phone: User's phone that registers with the SAR and provides encrypted dynamic and static data to the SAR.
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.
It can also be used as fallback foe Revault and Ajolote which are deleted key covenant structures. As such, that security - accessibility compromise is way more justified. For you go to fallback in those settings when your vault is already compromised.