Skip to content

[RFC] Dealing with RPCs that have a lot of positional options #22575

@achow101

Description

@achow101

There are several RPCs that have several positional options which make them difficult to work with. The following RPCs have 3 or more optional arguments:

  • gettxoutsetinfo
  • createwallet
  • getbalance
  • listreceivedbyaddress
  • listreceivedbylabel
  • listsinceblock
  • listtransactions
  • send
  • sendmany
  • sendtoaddress
  • walletcreatefundedpsbt
  • walletprocesspsbt

What can we do to make it easier for users to use these RPCs?


Here are a few possible solutions.

Options object

An oft suggested method is to use an options JSON object. This would replace all of the positional options with a single argument that contains a JSON object with each option named explicitly in it. This is a pattern we already use for several RPCs. This could be done in a backwards compatible way to minimize disruption to current users of those RPCs and new options would simply be added to this options object. However typing correctly formatted JSON can be difficult.

Encourage the use of named arguments

Since all positional arguments have names, it is possible to use named arguments rather than specifying them all positionally. Through the use of named parameters, users would be able to have largely the same effect as an options object but without needing to make correctly formatted JSON. Bitcoin Core already supports named parameters as described in the JSON-RPC 2.0 spec. Any client that conforms to JSON-RPC 2.0 would be able to use named arguments. Furthermore, bitcoin-cli has -named switch so that it is also easy for command line users and does not require correct JSON formatting.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions