Feature request: include on-chain sends in payment list

[danielgranhao]

trafficstars

In the same way a Payment can represent a channel closing if the type is PaymentType::ClosedChannel, it would be user-friendly if the payment list returned by list_payments() could also include transactions created by any of:

• send_onchain()
• sweep()
• refund()

[roeierez]

We follow the principle where the payments are those that affect the lighting balance (not onchain balance) so anything that affect the lightning balance is a valid candidate to be part of the list_payment API. Using this principle it makes sense to add special identifiers to the send_onchain & receive_onchain Since both of them represents today by lightning transactions (in & out) I suggest to add another two optional fields (send_onchain_tx, receive_onchain_tx) to the payment as these fields are useful anyway for the developer to show the relevant transaction to the user. This also makes it unnecessary to introduce another PaymentTypes. @danielgranhao What do you think?

Regarding sweep and refund which are pure onchain tx not sure we want to add it to the payments list but we can think of exposing it using a different API. @kingonly what do you think?

[danielgranhao]

Thanks for elaborating on the reasoning. That makes sense.

Having a different API to access onchain tx history would be cool!

[danielgranhao]

@roeierez I'm currently working on implementing this.

I'm adding an optional ReverseSwapInfo field to the payment details (an approach identical to how swaps are handled). The issue I'm seeing is that the db only stores FullReverseSwapInfos, and network requests are required to convert into the user-facing ReverseSwapInfo.

I think we need to cache in the db the lockup_txid and claim_txid to avoid accessing the network when listing payments, but I wanted to get feedback before working on such a solution.

[roeierez]

@danielgranhao I agree no network request should be done when the user asks for list_payments. I think we can safely cache these values for the list_payment purpose but use the cache only in list payments and keep doing network requests to get the up to date values in the other flows as today (refreshing the cached values as well). Reason is that we are considering also mempool transaction for these values which an be changed/overriden by the swapper. Does it sound reasonable to you? cc @ok300

[ok300]

A different approach could be as follows:

The Payment could include an optional rev_swap_id: Option<String>. If set, this invoice was associated with a reverse swap ID.

list_payments could show this payment was associated with a reverse swap with minimal overhead and without needing any network lookup. We could add an extra SDK method get_rev_swap_by_id to lookup the full rev swap addresses and details, if the user chooses to view them.

Would this cover your use-case? Or would you prefer the full reverse swap details to be included in list_payments?

[danielgranhao]

@ok300 That could work, but it would be preferable to have the reverse swap in the payment directly. It makes life easier for SDK users. Also, providing just the ID moves the network access problem a layer up.

[roeierez]

Would this cover your use-case? Or would you prefer the full reverse swap details to be included in list_payments?

I think it is not about full info or not but about being consistent since for swap in we show the SwapInfo object on the payment.