Migrating a threshold wallet

When this issue applies

This page addresses a narrow case: a threshold wallet has at least as many affected keys as a spending-path threshold, and its relevant script, descriptor and child public keys have not already been disclosed. In that case, the first spend can make individual weak-key tests possible before the transaction confirms.

It does not apply in the same way to single-signature outputs, a threshold wallet with fewer affected keys than the threshold, or a wallet whose script or descriptor is already known to the attacker. Those cases still require an exposure assessment, but a first-spend script reveal is not the new event. If the wallet is single-signature, the ordered procedure is on moving funds from an affected seed; the submission-route material below still applies to the transaction itself.

What becomes public during a spend

A P2WSH output contains a hash of the witness script. A valid spend supplies that script and the required signatures. When an unconfirmed transaction is publicly relayed, peers that receive it can inspect the script and its child public keys before a block confirms the spend. An attacker who can recover a threshold number of keys within that interval may attempt a conflicting spend with a more attractive fee.

The same witness-script disclosure occurs for nested P2SH-P2WSH. Its scriptSig also supplies the redeem-script witness program, while the witness supplies the complete witness script and signatures. Public relay therefore creates the same pre-confirmation inspection window.

The published candidate-space estimates vary by many orders of magnitude, so this mechanism does not establish that every such race is practical. It identifies when a hidden-script assumption ends and when a wallet-specific recovery estimate becomes relevant.

flowchart TB
  START["Signed migration transaction"] --> ROUTE{"Submission route"}
  ROUTE -->|"public relay"| MEM["Transaction enters public mempools
script visible before confirmation"]
  MEM --> WINDOW["Any viable key-recovery and
conflicting-spend attempt can begin"]
  WINDOW --> BLOCK["Confirmation closes the
unconfirmed race window"]
  ROUTE -->|"direct miner submission"| PRIV["Disclosure can be limited to service
and participating miner systems"]
  PRIV --> PBLOCK["Script becomes public when mined
or if transaction is otherwise relayed"]
  TAP["Available Taproot key-path spend"] -. "does not reveal script leaf" .-> PBLOCK

Direct submission can narrow pre-confirmation disclosure. It does not make a transaction private after it is mined and does not guarantee confirmation.

Charles Guillemet also described the complete-script condition, the possibility that copies already exist in provider systems or backups, and the public-mempool conflict window. He recommended a trusted private relay and named Slipstream as one example. Guillemet is Ledger's CTO, and Ledger sells competing signing devices; that affiliation bears on the recommendation and is disclosed without implying that the mechanism is wrong.

Submission options and limitations

MARA describes Slipstream as a direct transaction-submission service backed by MARA Pool. At the 1 August 2026 check, its portal required a client code and applied a minimum submission feerate. MARA's public material supports describing it as direct submission, but the portal terms do not establish a confidentiality or confirmation guarantee.

The separately published OpenAPI document describes transaction handling as best effort and says admission does not guarantee mining. Its request schema marks client_code as optional, while the portal says client codes are currently required. This archive did not submit a transaction to test which condition the service enforced on 1 August 2026.

A dated pool-share observation gives scale to that limitation. In a held copy of mempool.space's rolling one-month pool dataset, retrieved at 05:56 UTC on 1 August, MARA Pool had found 197 of 4,343 blocks in the response, or 4.54%. The total includes 44 blocks in the endpoint's Unknown category. If that share stays constant and network blocks arrive every ten minutes on average, the implied mean interval between MARA blocks is about 220 minutes, or 3.7 hours.

That is a backward-looking average, not an expected confirmation time for a submitted transaction. Pool share and block intervals vary, and acceptance, fee policy, conflicts and service behaviour remain separate conditions.

A time-stamped risk assessment

LLFOURN assessed the immediate risk of moving Mk4 multisig as low on 1 August, while warning that the same assessment might not hold a few days later. The post describes Unchained's cautious, one-size process as sensible for a KYC provider that knows its customer base, and notes that waiting means trusting the provider's eventual solution.

The date is part of the claim. It records how one analyst weighed speed and coordination at that moment; it is not a continuing guarantee about attacker capability or any provider's process.

Provenance of the recommendation

Rob Hamilton, an AnchorWatch co-founder, published the migration warning. Peter Todd subsequently endorsed direct miner submission as a possible way to reduce the public-mempool interval. PortlandHODL, who has described involvement in building Slipstream and lists an AnchorWatch affiliation, offered access codes during the incident. Charles Guillemet later published a similar recommendation while serving as Ledger's CTO. These relationships are disclosed because they connect the advice either to the service or to a competing hardware-wallet vendor. They do not establish that the technical mechanism is incorrect.

A reported migration outcome

PortlandHODL later reported that a transaction submitted through Slipstream and included in the block current when he posted had saved approximately 158.6 BTC from a 2-of-3 multisig wallet whose COLDCARD keys were likely exposed. The held post does not identify the transaction, wallet policy, competing-spend evidence or counterfactual outcome. This archive therefore records the statement as a reported service outcome and does not independently classify the funds as saved by Slipstream.

Before signing or submitting

1. Confirm the case. Identify the spending path, threshold, affected-key count and whether the script, descriptor or child public keys are already exposed.
2. Create and test the destination first. Use fixed firmware or another independently assessed generator, then verify backup and receive addresses on trusted displays.
3. Assess the candidate-space assumptions. Do not treat a lower or upper published scenario as a measured recovery time for the wallet.
4. Review the submission route. Check current service terms, fees, replacement behaviour, data handling and what happens if no block is found promptly.
5. Avoid leaving a residual unintentionally. Any spent input reveals its witness script. Confirm which outputs and derivation paths remain after the planned transaction.
6. Verify the final transaction independently. Check destination, amount, fee and change policy before collecting the threshold signatures.