Module cln_rpc::model::requests

source ·

Structs§

Enums§

  • [‘Write mode to determine how the record is updated:’, ’ * must-create: fails if it already exists.‘, “ * must-replace: fails if it doesn’t already exist.“, ’ * create-or-replace: never fails.’, “ * must-append: must already exist, append this to what’s already there.”, ’ * create-or-append: append if anything is there, otherwise create.’]
  • [‘The status of the forward to delete. You cannot delete forwards which have status offered (i.e. are currently active).’]
  • [‘Label of the invoice to be deleted. The caller should be particularly aware of the error case caused by the status changing just before this command is invoked!’]
  • [‘Expected status of the payment. Only deletes if the payment status matches. Deleting a pending payment will return an error.’]
  • [‘Fee rate style to use. This can be:’, ’ perkw - provide feerate in units of satoshis per 1000 weight (e.g. the minimum fee is usually 253perkw).‘, ’ perkb - provide feerate in units of satoshis per 1000 virtual bytes (eg. the minimum fee is usually 1000perkb).’]
  • [‘Funder plugin will use to decide how much capital to commit to a v2 open channel request.’, ‘There are three policy options, detailed below:’, ’ * match – Contribute policy_mod percent of their requested funds. Valid policy_mod values are 0 to 200. If this is a channel lease request, we match based on their requested funds. If it is not a channel lease request (and lease_only is false), then we match their funding amount. Note: any lease match less than 100 will likely fail, as clients will not accept a lease less than their request.‘, ’ * available – Contribute policy_mod percent of our available node wallet funds. Valid policy_mod values are 0 to 100.’, ’ * fixed – Contributes a fixed policy_mod sats to v2 channel open requests.’]
  • [‘A string that represents the log level.’]
  • [‘If neither in_channel nor out_channel is specified, it controls ordering.’]
  • [‘If specified, then only the forwards with the given status are returned.’]
  • [‘If neither in_channel nor out_channel is specified, it controls ordering.’]
  • [‘To filter the payment by status.’]
  • [‘Supplying level will show log entries related to that peer at the given log level.’]
  • [‘If neither bolt11 or payment_hash is specified, index controls ordering, by created (default) or updated.’]
  • [‘Whether the invoice has been paid, pending, or failed.’]
  • [‘It specifies the type of address wanted; currently bech32 (e.g. tb1qu9j4lg5f9rgjyfhvfd905vw46eg39czmktxqgg on bitcoin testnet or bc1qwqdg6squsna38e46795at95yu9atm8azzmyvckulcc7kytlcckxswvvzej on bitcoin mainnet), or p2tr taproot addresses. The special value all generates all known address types for the same underlying key.’]
  • [‘The name of the index to get the next value for.’, ’ created is incremented by one for every new object.‘, ’ updated is incremented by one every time an object is changed.’, ’ deleted is incremented by one every time an object is deleted.’]
  • [‘The subsystem to get the next index value from.’, ’ invoices: corresponding to listinvoices (added in v23.08).‘, ’ sendpays: corresponding to listsendpays (added in v23.11).’, ’ forwards: corresponding to listforwards (added in v23.11).’]