Enhanced Security for 2FA 2of3 - Recovery Key as Signing Key, 2FA Delays, and Social Recovery

[PeterMcBTC]

Hi Blockstream team,

I’d like to suggest an enhancement for Green Wallet’s 2FA 2of3 multisig setup. Would it be possible to:

• Make the recovery key a signing key, generated and stored securely on a second hardware wallet (e.g., a second Jade).
• Allow 2FA delays (e.g., configurable signing after several days for added security).
• Add social recovery options, like BitKey, to let trusted parties help recover funds in emergencies.

These improvements would enhance decentralization, eliminate recovery file vulnerabilities, and strengthen resistance to attacks. I'd love to hear your thoughts and if this could be explored in future updates.

Thank you!

[jgriffiths]

Hi @PeterMcBTC

• Make the recovery key a signing key, generated and stored securely on a second hardware wallet (e.g., a second Jade).

The 2of3 recovery key is a signing key, and can be used along with the primary key to sign 2of3 transactions without green server involvement. We don't expose this way of signing from the wallets, because that would leave total control of spending within the wallet software, which violates our trust assumptions (i.e. that given 2fa protection, the wallet alone is never sufficient to spend the users funds).

We are investigating allowing signing with the recovery key from watch-only wallets (so the recovery and main keys are not held by the wallet at the same time). This will likely arrive with a re-working of our 2of3 setup towards the end of the year or Q1 next year.

• Allow 2FA delays (e.g., configurable signing after several days for added security).

2FA settings allow you to change the timelock value to one of several values after which you can spend with the primary key alone. We have to limit the allowable values here because each allowed value creates a different address, making recovery intractable if we were to support all allowable values. If you meant something else here feel free to clarify.

• Add social recovery options, like BitKey, to let trusted parties help recover funds in emergencies.

I believe we are in the early planning stages of providing such a service with future updates to our multisig setups.

[PeterMcBTC]

Hi JGriffiths,

Thanks for the response!

Just to clarify: If the recovery key is a signing key, can I use it along with the primary key and descriptor (e.g., in Sparrow Wallet) to sign transactions without green server involvement? I was referring to generating the recovery key on a hardware wallet and being able to also sign with both the 2FA key and the recovery key when needed.

For the delays, I was asking specifically about a 2of3 setup where transactions can be sent after a 72-hour delay, similar to Swan Vault. Having that kind of flexibility for added security would be great in the future.

Social recovery and inheritance options also sound exciting—I’ll be looking forward to those developments!

[jgriffiths]

Just to clarify: If the recovery key is a signing key, can I use it along with the primary key and descriptor (e.g., in Sparrow Wallet) to sign transactions without green server involvement? I was referring to generating the recovery key on a hardware wallet and being able to also sign with both the 2FA key and the recovery key when needed.

The subaccount xpub path to the actual user recovery key used for signing a given input is m/3'/subaccount'/pointer, so it is possible to create a 2of3 subaccount with the xpub from a hardware wallet, it is then just a standard p2sh 2of3 multisig with the green, user, and recovery keys. The users key path is m/1/pointer for subaccount 0, and m/3'/subaccount'/1/pointer for other subaccounts. The Green key path is m/1/gait_path/pointer for subaccount 0 and m/3/gait_path/subaccount/pointer for other subaccounts. gait_path is a 16 level derivation path derived in a one-way fashion from the user mnemonics (in order to keep the server keys unique for each user wallet).

The above key scheme (which predates bip44 etc) isn't really compatible with current wallet behaviour since they expect bip44-like behaviour such as receive and change paths, consistent paths for all subaccounts, respecting the gap limit etc, none of which apply to the Green scheme. Trying to manually create a wallet that tracks a 2of3 account is probably beyond the abilities of most users at present.

I work on the underlying wallet support code (gdk), not the wallets directly, so I'm not sure what functionality is currently exposed to end users. But you can get a PSBT from gdk which has the correct user keypaths and should in theory be able to sign that with a HWW for the recovery key. Or you can get the raw tx from gdk and sign that also. I suspect green-cli is probably the most user friendly way to do recovery signing, but (a) that is a developer tool, and comes with usage disclaimers and (B) that doesn't satisfy your wish to use e.g. another wallet to actually make the transactions.

I think we are planning to add 2of3 recovery signing to the Green wallet apps at some point in the future, but I don't know when at this stage. Sorry that this answer probably doesn't help you in the immediate term!

For the delays, I was asking specifically about a 2of3 setup where transactions can be sent after a 72-hour delay, similar to Swan Vault. Having that kind of flexibility for added security would be great in the future.

2of3 accounts don't currently use timelocks, only 2of2. So unfortunately you can't do this at present. It is likely that when we implement advanced custody/recovery support, the default subaccount type will be 2of3 and options like this (and potentially others) will be supported though.