lightning/bolts#1344 adds an optional fulfillment_payload TLV to update_fulfill_htlc, gated by option_attribution_data.
This lets the final recipient return encrypted success-side data to the original payment sender, analogous to how update_fail_htlc.reason returns encrypted failure data. One motivating use case is proof of payment for spontaneous/keysend payments, where the sender chose the preimage and the preimage alone does not prove recipient acknowledgement.
rust-lightning should support originating, relaying, and sender-side decoding of this payload while preserving the successful-payment attribution data semantics defined in the BOLT PR, including padded fulfillment_payload_tlvs, intermediate-hop ammag obfuscation, and the final-vs-intermediate attribution HMAC rules.
lightning/bolts#1344 adds an optional
fulfillment_payloadTLV toupdate_fulfill_htlc, gated byoption_attribution_data.This lets the final recipient return encrypted success-side data to the original payment sender, analogous to how
update_fail_htlc.reasonreturns encrypted failure data. One motivating use case is proof of payment for spontaneous/keysend payments, where the sender chose the preimage and the preimage alone does not prove recipient acknowledgement.rust-lightning should support originating, relaying, and sender-side decoding of this payload while preserving the successful-payment attribution data semantics defined in the BOLT PR, including padded
fulfillment_payload_tlvs, intermediate-hopammagobfuscation, and the final-vs-intermediate attribution HMAC rules.