epiccurious
commented
10 months ago ACK
These could be sub-accounts of the real master-seed for recovery purposes.
if the real wallet is at m / {44,48,84,86}' / 0' / 0' / {0,1} / *
Then the fake wallet could be
m / {44,48,84,86}' / 0' / 1' / {0,1} /*
But the key origin info in the descriptor can lie and say: [fingerprint]/ {44,48,84,86}'/ 0'/ 0'/ {0,1}/* So it looks the same as a real wallet descriptor.
This works as long as the spend passphrase is not given out or it is a watch-only.
How would this work? Would distress sub-accounts be visible to the user in the standard wallet or only relevant for a recovery/sweep of funds? By sub-accounts, are you referring to a custom HD derivation path.
You COULD include the descriptors for the distress sub account as inactive in the Real wallet, for a combined balance, although care may be needed to not spend from it in a privacy reducing way. Or you could include two wallets when the Real passphrase is given, the distress and real wallet. Or you could just open the real wallets for the real passphrase and the distress wallets for the distress passphrase.
Go ahead and share your opinion because I don't have strong preferences. Keep in mind you could have a wallet passphrase written down hidden somewhere that's for more secret wallets that you rarely need to watch. So the encrypted wallet volumes do not have to be used only for plausible deniability. If say you trust say your family, you could even share a Bails USB and just use distinct wallet load passphrases and a shared Persistent Storage passphrase to not see one another's private wallet details. (if you don't keylog one another lol)
You'd recover the funds by restoring the m / {44,48,84,86}' / 0' / 1' / {0,1} /* account.
grinding for master xprvs to match the real one's fingerprint
How much of a time expensive would grinding be?
It takes about one minute on a single thread with a i5-1135g7
An other issue is you'd want these to be child keys of the real master xprv (then lie again on the key origin and fingerprint in xprv serialization to make the fake look like a master). But bip32 has only 2^31 hardened indexes so it's not guaranteed (but likely) to find an index that if treating the child xprv like a master xprv will produce the same fingerprint. But now you have a 32-bit + number you'd have to store to recover the plausibly fake private_keys_enabled wallet.
So that is the recovery of the fake vs spendability of the fake trade off. I'm siding towards watch-only. The updated create new seed process will allow creating watch-only wallets, so it's not a setup that wouldn't ordinarily exist if using Bails more as warm or cold storage.
BenWestgate
github-actions[bot]
Inspired by: OWASP User Privacy Protection Cheat Sheet
If wallets are placed into encrypted volumes, panic mode can load fake decoy watch-only wallets if the user entered their distressed password. The key origin information can be spoofed. These could be sub-accounts of the real master-seed for recovery purposes.
Loading a private_keys_enabled wallet is more difficult as in order to look like the real wallet, the master xprv needs to be in the descriptors, which means grinding for master xprvs to match the real one's fingerprint.
"Adversaries must have no way to know a panic mode already exists..." this means while the feature would be opt-in, every user whether they set-up panic mode or not, would have to have enough encrypted volumes created for plausible deniability of those who do use it.
I can possibly use Veracrypt Hidden Volumes for this. It must be able to be created and decrypted without an administration password setup.
"The password for the hidden volume must be substantially different from the password for the outer volume."
This applies regardless of if I use LUKS2 volumes or Veracrypt. A good default would be for people who do NOT use panic mode to have to enter their Persistent Storage Passphrase to Load their wallets. Then users who want a Panic Mode can create a "substantially different" passphrase for their Real wallet and an attacker will see the Fake wallet with the default passphrase.