Below is a refined technical document that clarifies the role of the temporary key and how the emergency/disaster UTXO is effectively unspendable except via the pre-signed “recovery transaction.” In particular, this version emphasizes that there is no extra script-based lock on the disaster UTXO; rather, it is simply sent to the temporary key Key_T, and the only valid signature to spend it is the one created (and then partially shared) by the custodian before Key_T was destroyed.

1. Overview
1. Temporary Key (Key_T):
• A fresh key pair generated by the custodian during setup.
• Used only to create partial signatures for the recovery transaction and the “disaster signal UTXO.”
• Destroyed immediately after, preventing both the user and the custodian from using it for any other purpose.
2. User’s Final Taproot:
• The user’s funds reside in a Taproot output with two internal paths:
1. Normal Path:  for daily spending.
2. Recovery Path:  activated only after the “disaster signal.”
3. Disaster Signal UTXO (Locked to Key_T):
• A small output paying to Key_T.
• No fancy script lock—just a standard single-key output controlled by Key_T.
• Critically, the custodian has already produced a partial signature that only works if this UTXO is spent in the final “recovery transaction.”
4. Recovery Transaction (Partially Signed):
• Consumes two inputs:
1. The user’s final Taproot via .
2. The disaster signal UTXO (locked to Key_T).
• Key_T’s partial signatures are included at setup.
• Once Key_T is destroyed, there is no other valid way to spend either input with Key_T—except using the already-produced partial signatures.
5. Disaster Activation:
• When the custodian broadcasts the “disaster signal transaction,” it finally places the Key_T-locked UTXO on-chain.
• The user then finalizes the “recovery transaction” by adding their signature, spending both the final Taproot and the newly created disaster UTXO together, and moving funds to safety.

2. Step-by-Step Design

2.1. Custodian Generates Temporary Key_T
1. Generate Key_T
• Create an ephemeral key pair .
• Keep  private; do not share it with the user.
2. Embed  in the User’s Taproot
• The user’s Taproot includes a Recovery Path that says “” can spend it.

2.2. Disaster Signal (Pre-Signed) Transaction
1. Construct an Unbroadcast TX
• The custodian prepares a minimal transaction that pays a dust-level output to .
• In normal Bitcoin usage, this is just a standard P2TR or P2PKH output for Key_T—no custom script needed.
2. No Extra Script Lock
• There is no special script logic preventing spending.
• The only reason this UTXO can’t be abused is that Key_T is destroyed after setup, so no one can re-sign new transactions with it.
3. Kept Off-Chain
• This “disaster signal TX” is not broadcast yet.
• It will be published on-chain only in an actual emergency.

2.3. Recovery Transaction (Partially Signed with Key_T)
1. Two Inputs
1. Final Taproot: Spent by .
2. Disaster UTXO: Locked to .
2. Custodian Signs with Key_T
• While  still exists, the custodian signs both inputs to create partial signatures.
• The user’s final Taproot input is partially signed by Key_T (the user must add their signature later).
• The disaster UTXO input is also partially signed by Key_T.
• The user cannot yet finalize or broadcast the recovery transaction because:
• The user still needs to add their own signature for the Taproot input.
• The disaster UTXO does not exist on-chain until the custodian broadcasts the signal TX.
3. No Lock
• There is no script-level lock on the disaster UTXO.
• The practical lock is that Key_T’s private key no longer exists after setup—so this partial signature is the only signature that can ever spend that UTXO.
4. Custodian Destroys 
• After generating the partial signatures, the custodian securely erases the private key.
• Result: No one can produce any new transaction with Key_T’s signature in the future.

2.4. Normal Operation
• The user’s final Taproot is spent day-to-day using the Normal Path .
• The “Recovery Path” is inert because:
1. The user doesn’t have Key_T.
2. The “disaster UTXO” is not even on-chain yet (so the partial signature for it is meaningless at this point).

3. Disaster Scenario
1. Custodian Broadcasts “Signal TX”
• This creates the Key_T-locked UTXO on-chain.
• Suddenly, the partial signature for that UTXO (created at setup) becomes usable.
2. User Detects the Disaster UTXO
• The user sees that the “signal TX” confirmed on-chain.
• The user retrieves the pre-signed “recovery transaction” file from storage.
3. User Adds Their Signature
• The user signs the Taproot input with Key_User in the  path.
• Key_T’s partial signature (from setup) covers the other half of that input as well as the disaster input.
4. Broadcast Recovery Transaction
• Now fully signed, it spends:
1. The user’s final Taproot (through the recovery path).
2. The disaster UTXO paying to .
• Outputs go to the user’s safe address (e.g., a new single-sig under user control).
5. User Recovers Funds
• This does not require the custodian’s cooperation at the time of disaster.
• The user’s funds are effectively rescued into their own address.

4. Security & Abuse Prevention
1. No Key_T After Setup
• Because the custodian destroyed Key_T, they cannot unilaterally spend the user’s Taproot.
• Nor can they re-spend the disaster UTXO in any other transaction.
2. User Can’t Trigger Recovery Prematurely
• The user cannot finalize the recovery transaction until the custodian broadcasts the signal.
• Attempting to do so earlier would fail because the second input (disaster UTXO) does not yet exist on-chain.
3. On-Chain Gating
• The existence of the Key_T-locked UTXO on-chain is the “signal.”
• The partial signatures produced during setup are the only valid signatures for spending it (since Key_T is gone).

5. Implementation Notes
1. Minimal Output for Disaster UTXO
• Typically must meet dust limits (e.g., ~330 sats for a P2TR) to be standard in Bitcoin mempool/policy.
2. SIGHASH Types
• Usually SIGHASH_ALL | ANYONECANPAY or a similar flexible combination.
• Ensures you can add the second input (the newly created UTXO) without invalidating Key_T’s signature.
3. Storage
• The user securely stores the partially signed recovery transaction offline.
• The custodian stores the unbroadcast “disaster signal TX.”
4. Privacy
• The final Taproot can look like a normal single-key Taproot on-chain. The second internal path is not revealed unless triggered.

6. Conclusion

This flow ensures:
• No script-based ‘lock’ on the Key_T UTXO. It’s a plain spend-to-Key_T output.
• No off-chain policy or key revelation at disaster time—only the pre-signed transaction is needed.
• No ongoing risk from the temporary key, since  is destroyed.
• Unilateral user recovery as soon as the custodian’s signal UTXO is published on-chain.

By relying on partial signatures from a short-lived Key_T, we effectively create a one-time “spend path” that only works when the “disaster UTXO” appears. This approach does not require any complex covenant scripts; it’s simply a clever combination of Taproot paths, partial signatures, and ephemeral key disposal.