Problem:
Users will be unlikely to remember a 5-7 word passphrase for their Persistent Storage, another 10 random character or 8+ word Core Wallet Encryption passphrase and another optional 5-7 word passphrase that regenerates one and ONLY one share to their backup (meaning it's salted against the identifier to select its rejection sampled NON-S index.)
Describe the solution you'd like
Since a Persistent Storage passphrase is unavoidable and we want it to offer protection for the hassle of needing to remember it to not regenerate the USB Stick. As well as default privacy (there's no privacy if they write the passphrase down and store it with the USB stick.)
We also think the default case of wallet encryption is smart in case an adversary takes control of the unlocked machine.
I'd like to share the passphrase between Bitcoin Core wallet encryption, the Persistent Storage and also generate ONE share with it.
That way during restoration, after k-1 shares have been entered the option to enter a passphrase appears in the GUI and entering it correctly will restore the master seed and encrypted wallet, which can be encrypted by that same passphrase.
Users who want to use a different passphrase on the wallet encryption may change it before blank wallet creation to avoid writing the encrypted wallet to the disk with the old passphrase. And Bails itself has no idea what the user used for the Persistent Storage passphrase.
Describe alternatives you've considered
Multiple passphrases including using KeepPass XC CLI to judge the entropy of the diff between the passphrases to warn the user it is too similar to their old passphrase or another passphrase to protect them in the case of one or any of them being compromised.
Problem:
Users will be unlikely to remember a 5-7 word passphrase for their Persistent Storage, another 10 random character or 8+ word Core Wallet Encryption passphrase and another optional 5-7 word passphrase that regenerates one and ONLY one share to their backup (meaning it's salted against the identifier to select its rejection sampled NON-S index.)
Describe the solution you'd like
Since a Persistent Storage passphrase is unavoidable and we want it to offer protection for the hassle of needing to remember it to not regenerate the USB Stick. As well as default privacy (there's no privacy if they write the passphrase down and store it with the USB stick.)
We also think the default case of wallet encryption is smart in case an adversary takes control of the unlocked machine.
I'd like to share the passphrase between Bitcoin Core wallet encryption, the Persistent Storage and also generate ONE share with it.
That way during restoration, after k-1 shares have been entered the option to enter a passphrase appears in the GUI and entering it correctly will restore the master seed and encrypted wallet, which can be encrypted by that same passphrase.
Users who want to use a different passphrase on the wallet encryption may change it before blank wallet creation to avoid writing the encrypted wallet to the disk with the old passphrase. And Bails itself has no idea what the user used for the Persistent Storage passphrase.
Describe alternatives you've considered
Multiple passphrases including using KeepPass XC CLI to judge the entropy of the diff between the passphrases to warn the user it is too similar to their old passphrase or another passphrase to protect them in the case of one or any of them being compromised.