The current way transactions are done is ‘in one go’ with creating the transaction and signing and broadcasting all done in one step using the safe-api command safe wallet transfer.
This won’t allow hardware wallets to be used (or any offline / air-gapped signing). A typical hardware wallet process requires a three step process: create unsigned transaction, sign the transaction with the hardware wallet, broadcast the signed transaction.
This topic is to explore the possibility of allowing this workflow.
Perhaps we could introduce some flags to safe wallet transfer
safe wallet transfer --create <from> <to> <balance> etc safe wallet transfer --sign <unsigned-tx-data> safe wallet transfer --broadcast <signed-tx-data>
I wonder if the --dry-run flag is potentially useful here?
Just spitballing, I realise this is a nice to have and can be done later, but thought if there were some simple wins here we might be able to look into it.
Although not in CLI atm (@bochaco can correct me on that) is has been a discussion recently. No login, everything is keys, so keys in a hw wallet is perfectly OK for advanced users. I agree possibly done later, but we have been debating going down that road now and the consensus is we should. We will have login/get_keys or whatever we call it, @JimCollinson is having UX debates as well, for onboarding and using known phrases. However underneath the tech already sees all id’s/websites/data storage an wallets as just keys.
Aye, we’ve chatted about the need for a basic ‘sign’ function which would allow you to pass in some func to do the signing. This could then be done wherever (hw wallet…). There’s not so much that needs done for it, more it’s a matter of getting SCL tidied up a bit so we can get to one sign function for all our network needs there, and then expose this over requiring a secret key to instantiate a client.
I’m so looking forward to be able to run CLI safe transfer (or even safe files put --recursive) and see the Trezor screen (or something like Samsung KeyStore in my mobile) asking for approval.
Is this also needed for threshold / elder signing? Threshold signatures in practice is really two layers to manage, the layer which allows separation of message signing vs broadcasting, but then also a second layer of comms protocol for how to get the partially signed messages distributed for further signing and eventual broadcast. Seems like the comms aspect would suit inclusion in bls-dkg (except for the ‘g’ meaning ‘generation’ so perhaps adding signing comms is stretching the scope too far?)
Possibly BIP174 Partially Signed Bitcoin Transaction Format is helpful for inspiration here.