Yeah, the finalize step is the “sign” step for the person that started the transaction. I really liked antioch’s steps here Transaction Round Naming Challenge - #52 by antioch
// SRS flow
send <addr> <amount> -o slate1.gtx /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx /* outputs 2/2 signed
// RSR flow
receive <addr> <amount> -o slate1.gtx /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx /* outputs 2/2 signed
It either:
- creates an empty “slate” or a “deal/offer” if we prefer to call it that or
- signs an existing slate passed through
-i(input) to produce a new slate and save it to file-o(output).
If the output is not defined, the output slate is printed to stdout. I’m not sure if the above format is good, but we likely want to have small commands that are composable and do one thing only because these make integrations simpler and add flexibility to integrations - the alternative could be unix-like behaviour with expecting the input through stdin and doing cat slate1.gtx | sign > slate2.gtx but I’m not sure how this works on other operating systems.
Note that there is no broadcast in the above flow. This is because we want to clearly separate the signing from broadcasting. The two can happen even on different devices e.g. hardware wallet signs, but doesn’t broadcast because it doesn’t have a connection to external world e.g. a node.
Since signing of the last signature is often accompanied with a broadcast, an alias command composition sign -i slate2.gtx -o tx.gtx && broadcast tx.gtx would be available.