2023 Mar 16

• More to add to the long list of things to look into: Erlay and Minisketch

• Review: anchor outputs are important for fee bumping commitment transactions, but why do you need to fee bump them? Because HTLCs’ cltv_expiry. Say you’re routing a payment, and upstream they claim the HTLC and you get the preimage, however your downstream channel partner goes offline and you can’t update to get a nice clean no-HTLC commitment tx. You have to broadcast the commitment tx on-chain

• It’s weird, in my mind I’ve had this abstraction of HTLCs being this separate thing on top of commitment txs that when they resolve you form a new commitment tx, but HTLCs hold actual concrete outputs on the commitment tx. When you do update_add_htlc, you are signing a new commitment tx with HTLC outputs and revoking previous states. It’s like I understood the concept of how these things function, but wasn’t connecting them properly.

• Feedback on my PR!

  • Add test for comparing cltv_expiry values (currently tests passing on >, but should also test failing on <)

  • Need to understand channelmanager.rs 3942

  • Check cases in process_pending_htlc_forwards (particularly in the non-MPP case, make sure PaymentClaimable always shows the actual received amount), understand what’s happening, switch from incoming vs. outgoing values. Cover with tests.

  • Note: so actually it reports the sender intended value instead of the actual value in both non-MPP and MPP case

• What does it actually mean when an HTLC is failed back? I thought that it’s like the HTLCs get cancelled/resolved. Does that mean that they commitment_signed revoke_and_ack a new commitment without the HTLC? It must be right? No matter what, these nodes will have to watch for previous commitment transactions (particularly the added failed one), but at least they won’t have this HTLC pending anymore.