doc: fix and extend htlc_accepted documentation for resolve

The documentation around the resolve response was outdated. CLN does
check the preimage and fails the HTLC incase of a mismatch.

Changelog-None

Author: daywalker90

cln-rpc/src/hooks.rs

@@ -789,7 +789,7 @@ pub mod actions{
         pub result: RbfChannelResult,
     }
 
-    /// ['Determines how the HTLC should be handled.', '', '`continue` means that the plugin does not want to do anything special and lightningd should continue processing it normally,', "i.e., resolve the payment if we're the recipient, or attempt to forward it otherwise. Notice that the usual checks such as sufficient fees and CLTV deltas are still enforced.", '', 'It can also replace the onion.payload by specifying a payload in the response. Note that this is always a TLV-style payload,', 'so unlike onion.payload there is no length prefix (and it must be at least 4 hex digits long). This will be re-parsed;', "it's useful for removing onion fields which a plugin doesn't want lightningd to consider.", '', 'It can also specify forward_to in the response, replacing the destination.', 'This usually only makes sense if it wants to choose an alternate channel to the same next peer, but is useful if the payload is also replaced.', '', 'Also, it can specify extra_tlvs in the response. This will replace the TLV-stream update_add_htlc_tlvs in the update_add_htlc message for forwarded htlcs.', '', 'If the node is the final destination, the plugin can also replace the amount of the invoice that belongs to the payment_hash by specifying invoice_msat.', '', '', '`fail` will tell lightningd to fail the HTLC with a given hex-encoded `failure_message` (please refer to BOLT #4 for details: `incorrect_or_unknown_payment_details` is the most common).', '', 'Instead of `failure_message` the response can contain a hex-encoded `failure_onion` that will be used instead (please refer to the BOLT #4 for details).', "This can be used, for example, if you're writing a bridge between two Lightning Networks. Note that lightningd will apply the obfuscation step to the value", 'returned here with its own shared secret (and key type `ammag`) before returning it to the previous hop.', '', '', '`resolve` instructs lightningd to claim the HTLC by providing the preimage matching the `payment_hash` presented in the call.', 'Notice that the plugin must ensure that the `payment_key` really matches the `payment_hash` since lightningd will not check and the wrong value could result in the channel being closed.']
+    /// ['Determines how the HTLC should be handled.', '', '`continue` means that the plugin does not want to do anything special and lightningd should continue processing it normally,', "i.e., resolve the payment if we're the recipient, or attempt to forward it otherwise. Notice that the usual checks such as sufficient fees and CLTV deltas are still enforced.", '', 'It can also replace the onion.payload by specifying a payload in the response. Note that this is always a TLV-style payload,', 'so unlike onion.payload there is no length prefix (and it must be at least 4 hex digits long). This will be re-parsed;', "it's useful for removing onion fields which a plugin doesn't want lightningd to consider.", '', 'It can also specify forward_to in the response, replacing the destination.', 'This usually only makes sense if it wants to choose an alternate channel to the same next peer, but is useful if the payload is also replaced.', '', 'Also, it can specify extra_tlvs in the response. This will replace the TLV-stream update_add_htlc_tlvs in the update_add_htlc message for forwarded htlcs.', '', 'If the node is the final destination, the plugin can also replace the amount of the invoice that belongs to the payment_hash by specifying invoice_msat.', '', '', '`fail` will tell lightningd to fail the HTLC with a given hex-encoded `failure_message` (please refer to BOLT #4 for details: `incorrect_or_unknown_payment_details` is the most common).', '', 'Instead of `failure_message` the response can contain a hex-encoded `failure_onion` that will be used instead (please refer to the BOLT #4 for details).', "This can be used, for example, if you're writing a bridge between two Lightning Networks. Note that lightningd will apply the obfuscation step to the value", 'returned here with its own shared secret (and key type `ammag`) before returning it to the previous hop.', '', '', '`resolve` instructs lightningd to claim the HTLC. The plugin gives the `payment_key`, which is the preimage for the `payment_hash` in the call.', 'lightningd hashes the `payment_key` and compares the result with the `payment_hash`. If the values do not match, lightningd fails the HTLC with `incorrect_or_unknown_payment_details`.', 'When the plugin resolves, lightningd skips the normal checks for a final node. These checks include the amount and the CLTV expiry.', 'The plugin must make sure that these values are correct. Otherwise it can accept the payment for the wrong amount.', 'If the plugin resolves without a `payment_key`, or with an invalid `payment_key`, lightningd stops with a fatal error.']
     #[derive(Copy, Clone, Debug, Deserialize, Serialize, PartialEq, Eq)]
     #[allow(non_camel_case_types)]
     pub enum HtlcAcceptedResult {

contrib/msggen/msggen/schema.json

@@ -43644,8 +43644,11 @@
               "returned here with its own shared secret (and key type `ammag`) before returning it to the previous hop.",
               "",
               "",
-              "`resolve` instructs lightningd to claim the HTLC by providing the preimage matching the `payment_hash` presented in the call.",
-              "Notice that the plugin must ensure that the `payment_key` really matches the `payment_hash` since lightningd will not check and the wrong value could result in the channel being closed."
+              "`resolve` instructs lightningd to claim the HTLC. The plugin gives the `payment_key`, which is the preimage for the `payment_hash` in the call.",
+              "lightningd hashes the `payment_key` and compares the result with the `payment_hash`. If the values do not match, lightningd fails the HTLC with `incorrect_or_unknown_payment_details`.",
+              "When the plugin resolves, lightningd skips the normal checks for a final node. These checks include the amount and the CLTV expiry.",
+              "The plugin must make sure that these values are correct. Otherwise it can accept the payment for the wrong amount.",
+              "If the plugin resolves without a `payment_key`, or with an invalid `payment_key`, lightningd stops with a fatal error."
             ]
           },
           "payload": {

doc/schemas/hook/htlc_accepted.json

@@ -229,8 +229,11 @@
           "returned here with its own shared secret (and key type `ammag`) before returning it to the previous hop.",
           "",
           "",
-          "`resolve` instructs lightningd to claim the HTLC by providing the preimage matching the `payment_hash` presented in the call.",
-          "Notice that the plugin must ensure that the `payment_key` really matches the `payment_hash` since lightningd will not check and the wrong value could result in the channel being closed."
+          "`resolve` instructs lightningd to claim the HTLC. The plugin gives the `payment_key`, which is the preimage for the `payment_hash` in the call.",
+          "lightningd hashes the `payment_key` and compares the result with the `payment_hash`. If the values do not match, lightningd fails the HTLC with `incorrect_or_unknown_payment_details`.",
+          "When the plugin resolves, lightningd skips the normal checks for a final node. These checks include the amount and the CLTV expiry.",
+          "The plugin must make sure that these values are correct. Otherwise it can accept the payment for the wrong amount.",
+          "If the plugin resolves without a `payment_key`, or with an invalid `payment_key`, lightningd stops with a fatal error."
         ]
       },
       "payload": {