Definition
A safe test piece is the smallest wallet-derived artifact Distribrute permits outside the high-trust or owner-controlled wallet boundary. The serialized artifact used by software is called the safe extract.
It has two jobs:
- Let an approved operator tool test whether a password candidate may be correct.
- Withhold the data required to turn that result into control of the wallet.
“Safe” has this narrow meaning. It does not mean the artifact is public, anonymous, or harmless in every context.
Wallet-specific construction
| Wallet | Included | Deliberately excluded | Why it cannot spend |
|---|---|---|---|
| Blockchain.com | One ciphertext block, IV, and derivation settings | Remaining wallet ciphertext, full GUID, addresses, keys | One block cannot reconstruct or decrypt the wallet |
| Bitcoin Core | Password-encrypted wallet encryption key (mkey), salt, and iteration count — not an HD seed or master private key | Encrypted private keys, public keys, addresses, other wallet records | The recovered wallet encryption key is not a Bitcoin signing key and has no private-key ciphertext to decrypt |
The two designs are intentionally different. There is no generic “wallet hash” that has the same security properties for every format.
Lifecycle
- A wallet-specific extractor creates the safe test piece from the encrypted wallet. Only the fields described above are placed in the operator artifact.
- High-trust authoring hashes the exact serialized bytes and binds that hash into signed work.
- The coordinator sends the artifact with a signed search chunk to an approved agent.
- The agent tests candidates and seals a possible match to Verify.
- Verify rechecks the signed artifact hash and applies the confirmation available for that custody mode.
Safe-test-piece creation does not itself prove that full-wallet verification will happen later. That is a separate custody-specific step: Verify can use the stored full wallet in a custodial case, while the owner’s wallet is the final ground truth during a non-custodial guided recovery.
The coordinator cannot substitute a different extract without invalidating the signed context.
What the operator can learn
An operator controls its own machine and must be treated as capable of inspecting the local search. If that machine finds the password, the operator may be able to observe the candidate despite the agent’s immediate sealed reporting. The security boundary therefore assumes the password alone is not spendable without the omitted wallet material.
The operator also sees the wallet family and the computational parameters required to test it. It does not receive the owner’s name, contact details, wallet balance, or complete address set as part of the work package.
Why a match is provisional
Minimal tests trade certainty for data minimization:
- Blockchain.com’s one-block check recognizes expected wallet-JSON fragments and can produce a rare false positive.
- Bitcoin Core’s operator check can recognize valid wallet-encryption-key padding without proving that a real private key decrypts correctly.
For this reason, operator match and verified recovery are different protocol states. A match does not trigger payout or wallet operations until Verify applies the strongest available ground truth.
Security properties
The design aims to guarantee that:
- no safe test piece contains a complete encrypted wallet;
- no safe test piece contains the combination of records needed to derive a spendable private key;
- the exact bytes being searched are bound into signed work;
- a result is tied to one assigned search chunk;
- a result is independently verified before it is accepted.
It does not guarantee that:
- a weak password cannot be found;
- an operator machine cannot observe the password it found;
- the source wallet or the owner’s computer is free from malware;
- every operator-side match is correct;
- a finite search will find the forgotten password.
For exact fields and checks, continue to Blockchain.com or Bitcoin Core.