[guardian] Add wallet behaviour draft BIP

[bitcoinguardian]

Implements wallet behaviour for the Guardian Address proposal.

The source code for the wallet implementation is available at https://github.com/bitcoinguardian/electrum. This serves as a model for self-custodial wallets, while custodial services may adapt the protocol to their infrastructure.

Guardian Signal tooling is available at https://github.com/bitcoinguardian/GASPv1-draft

A demo with testnet transactions and Guardian integration is available at https://github.com/bitcoinguardian/electrum/tree/master/demo

[murchandamus]

The described signaling mechanism is expensive and unreliable, and adds overhead to the setup. It is likely incompatible with basic security practices like airgap setups as it relies on the wallet to be synchronized with the mempool and blockchain. The motivating scenarios sound implausible. The proposal comes across as fairly convoluted, a simple 2FA co-signer or a multisig setup with distributed signers both seem superior.

I’m not convinced it works at all, as per the described scenario, the attacker gains physical access to the unlocked wallet and therefore could tweak the firmware to make it ignore the Guardian signal, or extract the key material and create the transaction with different software. Relying on the software of a compromised device to enforce security is not reasonable.

I’m not convinced this proposal is a net improvement, nor that it is technically sound.

[murchandamus]

Propagation of unconfirmed transactions is best effort. There is no guarantee that transactions will be seen by all nodes before they are confirmed.

[murchandamus]

This scenario is unconvincing. Why would Alice release Bob from the duress before sending the transaction if the signer is already unlocked?

[bitcoinguardian]

I acknowledge that the scenario in the BIP may seem contrived, as it simplifies a complex threat model for illustrative purposes. The example was inspired by Satoshi Nakamoto’s philosophical question from August 2010: "Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again." (https://satoshi.nakamotoinstitute.org/posts/bitcointalk/340/). While the Guardian Address protocol operates at the wallet/application layer rather than consensus, it aims to echo this concept by enabling a self-sovereign kill switch & emergency signal to protect assets across diverse custody environments.

To address your specific concern about the scenario’s plausibility (Alice releasing Bob before sending the transaction), the intent was to model a situation where temporary access to an unlocked device occurs, such as a stolen phone or brief duress, followed by the victim’s ability to act quickly. I’ve elaborated on this in my detailed response (#1972 (comment)), but I’m happy to revise the scenario to better reflect realistic threat models, such as pickpocketing or remote session compromise, if that would clarify the BIP's motivation.

[murchandamus]

How would you compare your proposal to a multisig setup with signing devices in multiple locations?

[bitcoinguardian]

@murchandamus

Thank you for the detailed technical review. You've identified legitimate limitations that I should address more explicitly in the BIP and refine. Let me respond to your specific concerns:

On Compromised Device Security

You're correct that Guardian Address cannot protect against sophisticated attackers who can extract keys from memory or modify wallet software. However, this criticism applies equally to any software based security mechanism including password managers, hardware wallet interfaces, and even multisig coordinators running on compromised devices.

Guardian Address doesn't claim to be a cryptographic guarantee. It's a coordination protocol that provides defence in depth for realistic threat scenarios:

User's phone is stolen while unlocked, but the user escapes and can signal from elsewhere using a pre-signed transaction

Even if an attacker compromises a self-custody wallet, the same Guardian signal simultaneously freezes exchange accounts, triggers security team alerts, and locks other services

Many services have withdrawal delays, 2FA verification, or identity checks that create windows where Guardian signalling is effective

The threat model is not "attacker has root access to device and unlimited time" - it's "attacker has temporary access and must navigate multiple services with their own security layers."

Guardians are another layer of defence.

On Scenario Plausibility

The example scenario describes device theft, not sustained physical coercion. Realistic cases include:

• Phone pickpocketed while unlocked at a cafe
• Mugging where victim unlocks device under duress, then escapes
• Border seizure of devices with active sessions
• Remote compromise where "unlocked" means authenticated web sessions, not physical device control

Additionally, bitcoin services often have anti-theft delays: exchanges require email 2FA, impose withdrawal windows, or require video verification for large amounts. These create realistic timeframes where Guardian signalling provides protection even when the attacker has initial access.

On Cost

You characterise the mechanism as "expensive." A Guardian lock signal transaction costs under $1 at current fee rates (2.31 sat/vB as of today) or approximately $5 at the BIP recommended 20 sat/vB for reliable confirmation during higher network activity. For an emergency security mechanism that can coordinate lockdown across multiple services and protect potentially significant holdings, this is not expensive.

To put this in perspective, a typical bitcoin transaction costs the same or more as a Guardian signal. Users routinely pay higher fees for routine transactions and the cost is less than a cup of coffee for a mechanism that could protect thousands or millions of dollars in fiat terms.

The cost is actually a feature, not a bug. It prevents spam while remaining accessible for legitimate emergency use. Characterising sub $5 on-chain signalling as "expensive" would similarly apply to any bitcoin transaction based protocol.

On Mempool Propagation

You're right that mempool propagation is best effort.

However wallets already monitor mempools for incoming payments, RBF detection, and fee estimation. This isn't introducing new requirements.

Finality provides signal confirmation, while mempool visibility enables rapid response (often critical in emergency scenarios), the protocol requires honouring confirmed signals, making the security guarantee time bounded rather than absent.

Multiple broadcast paths mitigate propagation issues. Users can broadcast through multiple RPC nodes or services simultaneously. If you check out the PoC signal tooling this is the example behaviour. Requiring confirmation means 10+ minute delays that may reduce the emergency response effectiveness.

The question isn't "is this perfect?" but "is this better than having no emergency signalling mechanism?" I believe imperfect propagation with 30 second to 10 minute response time is substantially better than the status quo of no signals. Guardian signals were detected and applied within seconds in my Electrum fork and testnet3 implementation.

On Airgap Compatibility

You note that the proposal is "likely incompatible with basic security practices like airgap setups." This limitation is already documented in the BIP section "Threat Model and Limitations":

"Guardian Addresses will not protect wallets that are airgapped or otherwise unable to query address state from the latest block height."

This is an acknowledged tradeoff. The protocol serves the majority of Bitcoin users who operate hot wallets, mobile wallets, or desktop wallets with Internet connectivity. For users who prioritise airgap security above emergency coordination capabilities, Guardian Address is not the appropriate tool and the BIP states this explicitly.

On Comparison with Multisig

Multisig and Guardian Address solve orthogonal problems:

• Multisig provides: Distributed authorisation for spending (requires multiple parties to approve)
• Guardian Address provides: Emergency lockdown coordination (one party can freeze across services)

Key differences:

Capability	Multisig	Guardian Address
Retrofit existing wallets	No	Yes
Emergency lockdown without all signers	No	Yes
Coordinate across custodial services	No	Yes
Prevent spending when attacker has M-of-N devices	No	Yes (if signal sent first)
Cryptographic spending constraints	Yes	No

A sophisticated user should use both; multisig for spending authorisation, Guardian Address for emergency coordination. They're complementary, not competing.

The value proposition that no other BIP addresses is cross-service emergency coordination via a single on-chain signal that can simultaneously:

• Lock self-custody wallets
• Freeze exchange/custodial accounts
• Alert security monitoring services
• Trigger incident response procedures
• Notify emergency contacts or insurance providers

On Physical Security Response Coordination

Beyond digital wallet locks Guardian Address enables a broader security response dimension that no other bitcoin protocol provides:

Deterrence through uncertainty: An attacker who gains device access faces fundamental uncertainty - they don't know if a Guardian lock has already been broadcast, how many services monitor it, what physical security response may be underway, or whether law enforcement has been alerted. This uncertainty itself has protective value, potentially causing attackers to abandon attempts rather than risk detection and apprehension. This significantly changes game theory outcomes by adjusting the risk/reward balance to favour the defender.

Immediate stakeholder notification: Security monitoring services, family members, business partners, or legal counsel can monitor the Guardian Address and receive instant alerts when a lock signal appears on-chain, enabling coordinated response before an attacker can complete theft.

Law enforcement coordination: Guardian signals provide timestamped, cryptographically verifiable evidence of theft attempts. A broadcast lock signal creates an immutable blockchain record that the wallet owner has declared their holdings under threat, which can be critical for investigations and prosecutions.

Insurance claim substantiation: For users with custody insurance or institutional policies, Guardian signals provide irrefutable proof of when control of assets was lost, simplifying claims and establishing clear timelines that satisfy insurers' evidentiary requirements.

Time buying for physical intervention: Even a 10 minute delay from digital Guardian locks allows critical time for contacting authorities, alerting building security, reaching physical safety, or coordinating with security teams. The Guardian signal serves as a self-sovereign "panic button" that buys time when every second matters.

This physical-digital coordination capability is unique to Guardian Addresses. Multisig requires coordinating multiple parties to act (slow and requires consensus), while timelocks operate on fixed schedules (inflexible and can't respond to emergencies). Guardian provides near instant, unilateral emergency coordination across both digital services and physical security response, which is a capability gap that no existing bitcoin protocol addresses.

On "Not Technically Sound"

I respectfully disagree with this characterisation. The technical criticisms you've raised are:

Expensive - At under $1 (current rates) to $5 (recommended rate), this is trivial for an emergency mechanism protecting significant holdings.

Best effort mempool propagation - Acknowledged. This is a tradeoff for rapid response. Imperfect ≠ unsound.

Airgap incompatibility - Already documented in the Threat Model section. The protocol serves connected wallets (the majority use case).

Attacker can modify software - This applies to any software security and doesn't make the protocol unsound.

The protocol is technically sound in that:

• The ABNF grammar is formally specified
• The state machine is defined with clear semantics
• The blockchain interaction is straightforward. Working implementation exists (Electrum fork with testnet demo)
• The signalling mechanism is cryptographically verifiable

Whether the security benefit justifies adoption is debatable, but the technical specification itself is sound.

Proposed Revisions

Based on your feedback, I'll revise the BIP to:

Lead with threat model clarity. Explicitly state upfront what attacks this does and doesn't protect against

Emphasise cross-service coordination rather than device compromise protection as the primary benefit.

Strengthen abstract/motivation: I submitted this proposal to the bitcoin-dev mailing list with a comprehensive abstract/motivation with more detail, but made more generic in the BIP.

Add comparison table to show how Guardian Address complements (not replaces) multisig, timelocks, and vaults.

While airgap incompatibility is documented, I'll make this more prominent by improving limitations visibility.

Request for Specific Guidance

To move this forward:

• If the concern is primarily about overstated claims, would you find the proposal acceptable with more conservative framing and explicit threat model boundaries?
• Are there specific technical changes to the protocol itself that would address your concerns, or is this primarily about positioning/motivation?

I believe there's genuine value in standardising an emergency coordination mechanism that works across both self-custody and custodial environments. I'm committed to revising the BIP to address legitimate concerns while preserving that core utility.

Apologies for the formatting issues, this is my first BIP and I'll get this resolved!

[bitcoinguardian]

Since these two BIPs build heavily on the work by Jameson Lopp, I'm interested in his thoughts too @jlopp