`issue_send_tx` equivalent in the V2 wallet API

The issue_send_tx in the original V1 API essentially did too much, creating a (sender-initiated only) transaction and posting it via HTTP all in in one go. In the V2 API, this was broken up into more granular API functions.

You can replicate this functionality in the V2 API by providing a send_args parameter in the call to the V2 init_send_tx as follows:

{
  "jsonrpc": "2.0",
  "method": "init_send_tx",
  "params": {
  "args": {
       "src_acct_name": null,
       "amount": "1000000000",
       "max_outputs": 500,
       "minimum_confirmations": 10,
       "num_change_outputs": 1,
       "selection_strategy_is_use_all": true,
       "message": "my message",
       "target_slate_version": null,
       "send_args": {
         "method": "http",
         "dest": "http://127.0.0.1:3415",
         "finalize": true,
         "post_tx": true,
         "fluff": true
       }
     }
  }
}

The workflow will then be exactly the same as the V1 issue_send_tx, with the send, locking, finalizing and posting operations operating subsequently and returning an error if there’s an issue during any one of them.

If you’re calling the API functions separately, the workflow would be something like this:

  • Call OwnerAPI::init_send_tx (with send_args set to null), and get a slate back
  • Exchange the slate with the other party (who will call ForeignAPI::receive_tx on their foreign API, regardless of whether it’s HTTP or file exchange)
  • Once the caller is happy that the other party has received the transaction (if sending via HTTP) or the output file has been created ready for sending, call tx_lock_outputs with the Slate, which is required before the next calls will work.
  • Call finalize_tx with the slate received from the other party
  • Call post_tx with the transaction in the slate.

The most important things to note here are:

  • tx_lock_outputs, which locks the sender’s outputs so they won’t be used in further transactions is not called automatically anywhere (except if you provide send_args in the call to init_send_tx (or init_invoice_tx)
  • post_tx is not automatically called anywhere, (except for the case where it’s specified in send_args)

Would appreciate if anyone wondering about these can let me know if this helps, if not I can refine with more/clearer information.

1 Like