Skip to content

Add support for fulfillment payload #3321

Draft
t-bast wants to merge 3 commits into
masterfrom
fulfillment-payload-support
Draft

Add support for fulfillment payload #3321
t-bast wants to merge 3 commits into
masterfrom
fulfillment-payload-support

Conversation

@t-bast

@t-bast t-bast commented Jun 19, 2026

Copy link
Copy Markdown
Member

This adds support for including a payload in update_fulfill_htlc that the recipient encrypts for the payer. This can be useful to transmit data atomically with the fulfillment of a payment. The main challenge is that intermediate nodes may drop or tamper with this fulfillment payload, which is why we include it in the HMACs of the attribution data, which lets senders detect which pair of nodes may be malicious.

See lightning/bolts#1344

Builds on top of #3320

TODO:

  • add official test vectors
  • cross-compat tests with LDK
  • store fulfillment payload inside the payment DB
  • add support for fulfillment payload in on-the-fly funding
  • correctly wrap payload when using dummy hops

t-bast added 3 commits June 17, 2026 16:28
We refactor the attribution data code to make it more consistent with
the rest of the Sphinx-related code. We add comments and intermediate
variables to make it more readable. We introduce intermediate classes
to hold data and add better symmetry between the success and failure
cases.

This will make it easier to implement trampoline attribution and add
fulfillment data (lightning/bolts#1344).
We correctly extract shared secrets (including trampoline shared
secrets) and detect when we're inside a blinded path to avoid
including attribution data. Note that we don't use the trampoline
shared secret yet, since full trampoline isn't implemented (see
#2819 for the full changes).

We add tests for attribution data with blinded paths and trampoline
payments.
This adds support for including a payload in `update_fulfill_htlc` that
the recipient encrypts for the payer. This can be useful to transmit
data atomically with the fulfillment of a payment. The main challenge
is that intermediate nodes may drop or tamper with this fulfillment
payload, which is why we include it in the HMACs of the attribution
data, which lets senders detect which pair of nodes may be malicious.

See lightning/bolts#1344
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant