Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance update_add_htlc with remote peer's custom records #8660

Merged

Conversation

GeorgeTsagk
Copy link
Collaborator

@GeorgeTsagk GeorgeTsagk commented Apr 17, 2024

Description

Based on #8633

This PR enhances the update_add_htlc message with a "custom records" field which may contain custom records that are meant to be transmitted to the direct peer.

This extra field is included in routerrpc.SendPaymentRequest and is also exposed in the forward interceptor

Closes #8618

@GeorgeTsagk GeorgeTsagk self-assigned this Apr 17, 2024
Copy link

coderabbitai bot commented Apr 17, 2024

Important

Review Skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@@ -93,6 +93,7 @@ func (r *forwardInterceptor) onIntercept(
CustomRecords: htlc.CustomRecords,
OnionBlob: htlc.OnionBlob[:],
AutoFailHeight: htlc.AutoFailHeight,
WireCustomRecords: htlc.CustomPeerRecords,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should just be htlc.ExtraData. This is everything else left over after we read all the current hard wired fields. Start on the latter commits, so this may have been something added elsewhere to manipulate the map version?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also CustomPeerRecords doesn't exist yet

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should just be htlc.ExtraData. This is everything else left over after we read all the current hard wired fields. Start on the latter commits, so this may have been something added elsewhere to manipulate the map version?

Don't really get the idea here. Do we want to never decode ExtraData and hand it over the RPC or do we want to decode it, populate fields that we understand, and then hand over the leftovers?

The latter doesn't really make sense to me, and if we want to stick with something closer to the former we're off-loading tlv related decoding responsibilities to the user, which doesn't really make sense? i.e they would have to know which key is for blinding point or custom records etc

also CustomPeerRecords doesn't exist yet

Probs lost in the rebase, will address

lnwallet/channel.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@Crypt-iQ Crypt-iQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first pass done, need to go over it again though

lnrpc/routerrpc/forward_interceptor.go Outdated Show resolved Hide resolved
lnrpc/routerrpc/router_backend.go Show resolved Hide resolved
routing/router.go Show resolved Hide resolved
@@ -93,6 +93,7 @@ func (r *forwardInterceptor) onIntercept(
CustomRecords: htlc.CustomRecords,
OnionBlob: htlc.OnionBlob[:],
AutoFailHeight: htlc.AutoFailHeight,
WireCustomRecords: htlc.CustomPeerRecords,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also CustomPeerRecords doesn't exist yet

routing/router.go Show resolved Hide resolved
lnrpc/routerrpc/router.proto Outdated Show resolved Hide resolved
htlcswitch/interceptable_switch.go Outdated Show resolved Hide resolved
htlcswitch/interceptable_switch.go Outdated Show resolved Hide resolved
htlcswitch/interceptable_switch.go Outdated Show resolved Hide resolved
htlcswitch/interceptable_switch.go Outdated Show resolved Hide resolved
htlcswitch/link.go Outdated Show resolved Hide resolved
htlcswitch/link.go Outdated Show resolved Hide resolved
lnwallet/channel.go Outdated Show resolved Hide resolved
lnwallet/channel.go Outdated Show resolved Hide resolved
@GeorgeTsagk GeorgeTsagk changed the base branch from master to custom-channels-integration-rpc-channel May 2, 2024 14:50
@GeorgeTsagk GeorgeTsagk force-pushed the interceptor-wire-records branch 2 times, most recently from e9bd133 to 5203776 Compare May 2, 2024 18:02
@guggero guggero changed the base branch from custom-channels-integration-rpc-channel to custom-channels-integration May 2, 2024 18:54
@guggero guggero force-pushed the custom-channels-integration branch from 15abb14 to 09b34f1 Compare May 14, 2024 07:49
@lightninglabs-deploy
Copy link

@GeorgeTsagk, remember to re-request review from reviewers when ready

@dstadulis
Copy link
Collaborator

Fixes lightninglabs/taproot-assets#897

@GeorgeTsagk GeorgeTsagk force-pushed the interceptor-wire-records branch 2 times, most recently from ac58e73 to 3163902 Compare May 15, 2024 14:53
@GeorgeTsagk GeorgeTsagk changed the base branch from custom-channels-integration to 0-19-staging May 15, 2024 14:54
@GeorgeTsagk GeorgeTsagk changed the title Add interceptor access to update_add_htlc remote peer's custom records Enhance update_add_htlc with remote peer's custom records May 15, 2024
Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good! Might need a rebase on top of @ffranr's latest state of #8633 (not sure if the unit test failures come from there or from this PR).

channeldb/channel.go Show resolved Hide resolved
lnwallet/channel.go Show resolved Hide resolved
lnwallet/channel.go Outdated Show resolved Hide resolved
lnwallet/channel.go Show resolved Hide resolved
lnwire/custom_records.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass, a few high level comments:

  1. Already noted by other reviewers, but restart flows need some more attention here (both including the custom fields and ensuring we always have this data persisted)
  2. Meta/personal preference: move itest to the end of the PR rather than having several iterations of it throughout the code
  3. One consideration that this PR introduces is that we're now going to store all the custom records that we're send with a HTLC, which could result in our storing a whole lot of junk that our peers send us - this was originally discussed when we added the update that allows us to store this data. I originally thought that a good way to approach this would be to allow users to specify the custom TLV values they want to store (or hardcode some notable ones that we want to keep by default), but I haven't fully thought that design through tbh.

itest/lnd_forward_interceptor_test.go Outdated Show resolved Hide resolved
itest/lnd_forward_interceptor_test.go Outdated Show resolved Hide resolved
65537: []byte("test"),
},
}
stream := alice.RPC.SendPayment(sendReq)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to test across restarts as well to get coverage for this comment

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this to the tracking issue.

htlcswitch/interfaces.go Outdated Show resolved Hide resolved
itest/list_on_test.go Outdated Show resolved Hide resolved
@@ -894,8 +931,12 @@ func (lc *LightningChannel) diskHtlcToPayDesc(feeRate chainfee.SatPerKWeight,

// Ensure that we'll restore any custom records which were stored as
// extra data on disk.
if len(htlc.ExtraData) != 0 {
pd.CustomRecords = fn.Some[tlv.Blob](htlc.ExtraData)
if len(htlc.CustomRecords) != 0 {
Copy link
Collaborator

@carlaKC carlaKC May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're setting the CustomRecords values above, we're not actually persisting them using the workaround added in #7710, which means that in certain restart cases we won't restore these records (diff to test db restore here).

So as-is we'll always have htlc.CustomRecords=0 because we're not persisting them with the channeldb.HTLC that needs to be turned into a PaymentDescriptor here.

The restart flow always takes me forever to reload into my brain, tried to write it all down here if that's at all helpful.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, persistence is missing atm.

So I'm not sure if the best way forward is persisting this as part of channeldb.HTLC or channeldb.PaymentCreationInfo as suggested here

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm not sure if the best way forward is persisting this as part of channeldb.HTLC or channeldb.PaymentCreationInfo as suggested #8660 (comment)

We need persistence in channeldb.HTLC so that the node that receives the incoming HTLC with custom TLVs is robust against restarts:

  1. HTLC is irrevocably committed on the channel
  2. Receiving node restarts before forwarding through the switch
  3. HTLC is restored from disk (no custom records)
  4. Interceptor receives HTLC without custom records

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this to the tracking issue.

return err
}

addMsg.CustomRecords = r
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to be overloading the CustomRecords field here?

  • pd.CustomRecords are the records we received on the incoming HTLC's update_add_htlc
  • addMsg.CustomRecords are the records that we're going to pack for the outgoing HTLC's update_add_htlc

This has the impact of always relaying all of the custom TLVs that we get on the incoming update_add_htlc to the outgoing update_add_htlc - confirmed this with a quick itest hack - and I don't see anything in the original issue saying that we want to do this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice catch
Agree, we don't want this side effect of naively relaying everything

I believe we actually want to block any type of relaying. These records should be propagated all the way until the interception point, where the user may decide if any outgoing htlc wire records will be defined

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assumed not, can prob easily fix by just adding a separate field to the intercepted packet.

Copy link
Collaborator

@guggero guggero May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was actually introduced in a previous PR (#8633) that added the interceptor logic. I'll address this in a later PR, added it to the tracking issue for now: #8769
We really are blocked by this PR (which is just one piece in a long series of PRs), so I'll want to merge this into the staging branch asap and then address any remaining issues later.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous PR is correctly using this field to ResumeModified with CustomRecords that are provided by the interceptor.

Here, we're overloading it with the incoming update_add_htlc's CustomRecords (which introduces the issue). The fix is pretty simple - just add a field to htlcPacket and surface it separately on the interceptor?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patch to fix is trivial, messy test to confirm that it solves the problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, was looking at it the wrong way around... Thanks a lot for the patch, happily took it in 🙏

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the patch

❤️ it needs gofmt :')

lnwire/custom_records.go Outdated Show resolved Hide resolved
@@ -2568,6 +2574,11 @@ func (h *HTLC) serializeExtraData() error {
records = append(records, &b)
})

records, err := h.CustomRecords.ExtendRecordProducers(records)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add test coverage for serialization change?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added that to the tracking issue.

return err
}

addMsg.CustomRecords = r
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patch to fix is trivial, messy test to confirm that it solves the problem.

itest/lnd_forward_interceptor_test.go Show resolved Hide resolved
Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🎉
Any remaining cleanups/unit tests are tracked here: #8769.

Merging to staging branch to unblock other work.

@guggero guggero merged commit 966f41f into lightningnetwork:0-19-staging May 22, 2024
22 of 27 checks passed
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.

routing+rpc: enable senders to set a custom first-hop TLV blob for update_add_htlc
7 participants