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 |
| Electrum legacy v1/v2 | One IV and one ciphertext block from an encrypted seed, xprv, or imported key | Remaining encrypted field, public reference, addresses, and other wallet records | One block cannot reconstruct the encrypted secret or wallet |
| Electrum 2.8+ BIE1 | Per-encryption ephemeral public key and the first 96 ciphertext bytes | Remaining wallet ciphertext, full-file HMAC, xpub, keys, complete address set, balances, and history | The short segment cannot reconstruct or authenticate the wallet |
MultiBit Classic .key | OpenSSL salt and the first encrypted WIF block | Remaining WIF ciphertext, complete private key, and other backup lines | The bounded WIF prefix revealed by a match is incomplete and not spendable |
| MultiBit HD | First 32 encrypted bytes covering the supported IV layouts | Remaining wallet, encrypted keys, addresses, and history | The decrypted check is only a bitcoinj format header |
MultiBit Classic .wallet | Scrypt settings, salt, and the final two blocks of one encrypted key | Remaining protobuf wallet and complete encrypted key | The decrypted check is only a padding block; the key bytes remain behind omitted CBC data |
The 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. Custodial cases use the high-trust path; non-custodial owners can use the customer wallet extractor locally. 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.
Customer-side extraction
The customer extractor serializes the same engine output used by high-trust authoring. Its offline
CLI and GUI support Bitcoin Core, exported Blockchain.com backups, Electrum, and MultiBit without a
network dependency or automatic submission. A separate opt-in Blockchain.com build contacts only
blockchain.info to retrieve the owner’s encrypted backup by GUID before deriving the same one-block
safe extract.
Local creation keeps the complete wallet out of Distribrute’s custody, but the resulting extract is still case material—not something to publish. It reveals the wallet family and computational parameters, is eventually sent to operator devices, and retains every format-specific disclosure in the table above. The owner currently transfers it through a controlled post-review handoff; the public request form does not accept extract strings.
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 direct owner identity or contact fields, wallet balance, transaction history, or a complete address set as part of the work package. It does see every candidate in its assigned range. Candidate strings and the recovered password can themselves contain personal information, so the safe-test-piece boundary should not be described as password anonymity.
There are format-specific metadata limits. After testing the correct password, the short Electrum
BIE1 segment may reveal the opening of the compressed wallet JSON. On some Electrum versions through
4.0, that can include a prefix of the first wallet address. A MultiBit Classic .key match reveals
the first 16 WIF characters—roughly 10–11 bytes of encoded private-key material—but not the complete
WIF or a spendable key. See Electrum and
MultiBit for the exact boundaries.
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.
- Electrum legacy checks recognize one decrypted field block, while the BIE1 check validates only a short encrypted segment. Both require full-wallet confirmation.
- MultiBit checks recognize a WIF prefix, bitcoinj header, or padding block. These structural matches also require full-wallet confirmation.
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.
- a correct password will open a wallet with spendable value or produce an operator payout.
For exact fields and checks, continue to Blockchain.com, Bitcoin Core, or Electrum, or MultiBit. For the success-funding boundary, read Operator rewards and settlement.