static_tx_addr_proposal.md

Static withdraw address implementation proposal

Database

Presumably, this is where the static withdraw address for each user is stored, along with existing user information. Something like ALTER TABLE will be issued to extend the existing database with at least the two new columns:

• a value e.g. static_withdraw_address_is_configured (or something more concise) indicating whether the user has configured a static withdraw address, stored as a Boolean (or similar) and initialized to false for all users
• a value e.g. withdraw_address to hold the user-configured static withdraw address, stored as CHAR(34) (same type as existing address column) and uninitialized by default (it is not to be accessed unless the static_withdraw_address_is_configured). Or, if the datatype has a reliable way for indicating it is uninitialized/invalid, that may be used instead creating the static_..._is_configured column, particularly if doing so is more convenient.

The README.md will need to be updated to add these columns in the example database initialization script.

Q: would it then be beneficial to rename/alias the current column address (i.e. for depositing to the wallet) to something more descriptive, e.g. deposit_address, for consistency/better contrast with the new withdraw_address column?

Functions to add/change:

User commands:

• Set/update static withdraw address: [pick a name]. Likely errors: if missing or malformed address: display help, do not change any of user's configuration. Unlikely errors: couldn't update the database for some reason.
  • Check if static withdraw address set
  • Get static withdraw address
  • A command for both above purposes (Q: is there an existing end-user command for summarizing their wallet info where this would be added? There doesn't seem to be one listed in %help.)
• Unset static withdraw address (no arguments)
• Withdraw: change to accept only an amount and implicitly use the static address. If an address is specified in the command, then do not use the static address. (Currently it uses a fixed number of positional arguments; this might need to change to a variable list, i.e. *args.)

Database queries:

• Get static withdraw address

• Check if static withdraw address configured (can be combined with the "get" function by either returning a tuple (is_configured, addr), or a single value such that of static withdraw address is not configured, return a value such as None, '', or some named value NOT_SET (the calling/consuming function must expect the designated not-set value). (I sort of prefer the out-of-band tuple approach if using meaningful None causes problems, but I wouldn't expect it to be a problem compared to say, something that is normally a Boolean.)

• Set/Update static withdraw address

• Unset static withdraw address (might wipe the address stored in the database as part of this)

• Any existing queries that get all fields for a user must add handling of the new column(s).

Other:

• add static withdraw address attributes to User class