{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "additionalProperties": false, "required": [ "onion", "first_hop", "payment_hash" ], "properties": { "onion": { "type": "hex", "description": "hex-encoded 1366 bytes long blob that was returned by either of the tools that can generate onions. It contains the payloads destined for each hop and some metadata. Please refer to [BOLT 04][bolt04] for further details. If is specific to the route that is being used and the *payment_hash* used to construct, and therefore cannot be reused for other payments or to attempt a separate route. The custom onion can generally be created using the `devtools/onion` CLI tool, or the **createonion** RPC command" }, "first_hop": { "type": "object", "description": "instructs Core Lightning which peer to send the onion to. It is a JSON dictionary that corresponds to the first element of the route array returned by *getroute*", "required": [ "id", "amount_msat", "delay" ], "properties": { "id": { "type": "pubkey", "description": "node id for the peer. Use any available channel available to this peer" }, "amount_msat": { "type": "msat", "description": "the amount to add an HTLC for millisatoshis" }, "delay": { "type": "u16", "description": "the number of blocks delay of blocks on top of the current blockheight" } } }, "payment_hash": { "type": "hash", "description": "specifies the 32 byte hex-encoded hash to use as a challenge to the HTLC that we are sending. It is specific to the onion and has to match the one the onion was created with" }, "label": { "type": "string", "description": "can be used to provide a human readable reference to retrieve the payment at a later time" }, "shared_secrets": { "type": "array", "description": "a JSON list of 32 byte hex-encoded secrets that were used when creating the onion. Core Lightning can send a payment with a custom onion without the knowledge of these secrets, however it will not be able to parse an eventual error message since that is encrypted with the shared secrets used in the onion. If *shared_secrets* is provided Core Lightning will decrypt the error, act accordingly, e.g., add a `channel_update` included in the error to its network view, and set the details in *listsendpays* correctly. If it is not provided Core Lightning will store the encrypted onion, and expose it in *listsendpays* allowing the caller to decrypt it externally. If it is not provided the Core Lightning node does not know how long the route is, which channels or nodes are involved, and what an eventual error could have been. It can therefore be used for oblivious payments", "items": { "type": "secret" } }, "partid": { "type": "u16", "description": "if provided and non-zero, allows for multiple parallel partial payments with the same *payment_hash*" }, "bolt11": { "type": "string", "description": "if provided, it will be returned in *waitsendpay* and *listsendpays* results" }, "amount_msat": { "type": "msat", "description": "used to annotate the payment, and is returned by *waitsendpay* and *listsendpays*" }, "destination": { "type": "pubkey", "description": "if provided, it will be returned in **listpays** result" }, "localinvreqid": { "type": "hash", "description": "`localinvreqid` is used by offers to link a payment attempt to a local `invoice_request` offer created by lightningd-invoicerequest(7)" }, "groupid": { "type": "u64", "description": "grouping key to disambiguate multiple attempts to pay an invoice or the same payment_hash" }, "description": { "added": "v0.11.0", "type": "string", "description": "if provided, it will be returned in *waitsendpay* and *listsendpays* results" } } }