Wallet import export

[hodlwave]

""" Hey @hodlwave, it seems that Fully Noded and this project are a perfect match.

Would you be open to supporting this wallet import export method?

It would make using a Proof-Wallet on FN incredibly easy and work with its psbt architecture nicely. """ (src: @Fonta1n3 in https://github.com/hodlwave/proof-wallet-v1/issues/1)

[hodlwave]

I'm currently refactoring Proof Wallet on the use-key-origin branch to import and export descriptor keys (i.e. key origin + account extended key).

To summarize...

• The create-wallet program will produce a BIP39 mnemonic and a descriptor key like [aabbccdd]tpub... , which corresponds to an extended public key at the m derivation path (can't use m/48' because the Bitcoin Core RPC doesn't expose child extended key derivation as of v0.20.1)
• The view-addresses program imports:
  • M value (CLI arg)
  • N value (CLI arg)
  • BIP39 mnemonic (default, optional, in the REPL)
  • N descriptor keys (in the REPL)
• The sign-psbt program imports:
  • M value (CLI arg)
  • N value (CLI arg)
  • BIP39 mnemonic (default, optional, in the REPL)
  • N descriptor keys (in the REPL)
  • base64-encoded psbt

Internally, Proof Wallet builds the descriptor using the provided inputs always in the form wsh(sortedmulti(M, dkey1, dkey2, ... dkeyN)).

IIUC, there would be nothing different to export for create-wallet, but theoretically, view-addresses and sign-psbt could import the BlockchainCommons JSON blob in lieu of M, and the N descriptor keys. At first thought, I think this might make the code more complex without a huge benefit to the UX, but I will think on it some more. Open to be convinced otherwise as well :)

[Fonta1n3]

At the end of the day it is fairly trivial for the user to do it manually.

Is there a reason we need to supply proof-wallet with individual descriptor keys instead of the whole shebang wsh(sortedmulti(M, dkey1, dkey2, ... dkeyN)) in one go?

[hodlwave]

Is there a reason we need to supply proof-wallet with individual descriptor keys instead of the whole shebang wsh(sortedmulti(M, dkey1, dkey2, ... dkeyN)) in one go?

Are you asking specifically about the format of descriptor data FullyNoded might display for someone to load into Proof Wallet before viewing their addresses or signing transactions? If so, my thinking about this is that users would instead print out this data as part of a multisig registration step they perform on each cosigner (i.e. using the descriptor and each BIP39 mnemonic to verify that all the cosigners are in consensus about the wallet by checking the first receiving address). After this registration step, the user could store this paper securely with their BIP39 mnemonic for the lifetime of the wallet. Interactions with FullyNoded could thus be limited to transferring unsigned PSBTs to the airgapped computer and signed PSBTs back to FullyNoded.

I haven't had the chance to test out FullyNoded with Proof Wallet yet so apologies if I misunderstood your question; let me know if that makes sense or not :)

[Fonta1n3]

Oh no, not asking anything FN specific. Just generally. Well understood! Will test out the key origin branch asap.