holdinvoice RPC plugin

[daywalker90]

This PR introduces "holdinvoice", a rpc plugin that offer 4 methods to hold invoices as per @niftynei request #6358 (comment)

• holdinvoice: creates an invoice, adds the payment_hash to the list of invoices to hodl
• holdinvoicesettle: allows htlcs to this payment_hash to settle
• holdinvoicecancel: fails back all htlcs for this payment_hash
• holdinvoicelookup: reports back information about a payment-hash that's being held

While doing this i improved the performance (almost 2 orders of magnitude less ressouces usage, the cpu usage was misleading in my grpc pr since lightningd was using quite a bit, which now it does not) and a bunch of other things in comparison to the earlier grpc version .

I also added some tests (they are not the best but cover some basic stuff) that i used in combination with 2 local regtest nodes.

Some things to note:

• cln can't accept htlcs for expired invoices (while lnd can)
• the plugin will automatically cancel htlcs if the invoice expiry is close (CANCEL_HOLD_BEFORE_INVOICE_EXPIRY_SECONDS). This will lead to a holdstate "canceled" and htlcs arriving in the CANCEL_HOLD_BEFORE_INVOICE_EXPIRY_SECONDS window will also be rejected
• the plugin will automatically cancel a htlc if the htlc is close to expiry on chain (CANCEL_HOLD_BEFORE_HTLC_EXPIRY_BLOCKS) this can lead to a holdstate transition from accepted -> open
• the plugin will only accept actual amount_msat values > 0 (not any) and values for expiry and cltv that are greater than CANCEL_HOLD_BEFORE_INVOICE_EXPIRY_SECONDS and CANCEL_HOLD_BEFORE_HTLC_EXPIRY_BLOCKS respectivley

I'm still not certain if my values for

pub const CANCEL_HOLD_BEFORE_INVOICE_EXPIRY_SECONDS: u64 = 1_800;
pub const CANCEL_HOLD_BEFORE_HTLC_EXPIRY_BLOCKS: u32 = 6;

are good or not. Feedback welcome.

[evd0kim]

@daywalker90
here is small commit which bumps cln-rpc and cln-plugin to the most recent versions.

bump.patch.txt

[daywalker90]

Thanks @evd0kim ! I applied the patch and also made the invoice descriptions in the tests unique so they are identifiable when testing.

[daywalker90]

689b85f: While testing the integration with this new version and robosats i noticed the plugin is not doing anything if the invoice has no payment attempts and expires. Previously it returned the state OPEN even after such an invoice expired, but i think it makes more sense that it returns CANCELED instead.

[daywalker90]

I found an inconsistency with lnds behaviour and this makes actually more sense: Plugin now switches to CANCELED if a htlc is close to expiry instead of back to OPEN.

[daywalker90]

Also, i think i found another big problem: If while holding a htlc the channel gets force closed there is no way for me to settle the invoice anymore since when the plugin returns "result": "continue" all the htlcs will be rejected instead of settled, even when there is plenty of cltv to go for the htlc. This could be used to scam in certain use cases for hold invoices. Any ideas for this? @rustyrussell @cdecker @niftynei

[daywalker90]

I could listen to channel_state_changed and settle in case of force closes but this would make for bad user experience imo and i don't know how safe this would be.

I tried the force close case with lnd and i was able to settle the htlc onchain to myself in the block window between first evidence of a force close onchain and the htlc timeout height.

[daywalker90]

• rebased on master
• updated cln deps
• rewrote the tests with the pyln-testing framework
• new test for force close -> settle holdinvoice
• don't wait in holdinvoicelookup for htlcs in channels that are not CHANNELD_NORMAL | CHANNELD_AWAITING_SPLICE

[cdecker]

This was moved to the lightningd/plugins repository: lightningd/plugins#482