-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Enhance update_add_htlc
with remote peer's custom records
#8660
Conversation
Important Review SkippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 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? TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Additionally, you can add CodeRabbit Configration File (
|
@@ -93,6 +93,7 @@ func (r *forwardInterceptor) onIntercept( | |||
CustomRecords: htlc.CustomRecords, | |||
OnionBlob: htlc.OnionBlob[:], | |||
AutoFailHeight: htlc.AutoFailHeight, | |||
WireCustomRecords: htlc.CustomPeerRecords, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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
@@ -93,6 +93,7 @@ func (r *forwardInterceptor) onIntercept( | |||
CustomRecords: htlc.CustomRecords, | |||
OnionBlob: htlc.OnionBlob[:], | |||
AutoFailHeight: htlc.AutoFailHeight, | |||
WireCustomRecords: htlc.CustomPeerRecords, |
There was a problem hiding this comment.
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
833c121
to
ffb0718
Compare
e9bd133
to
5203776
Compare
5203776
to
a3033a9
Compare
15abb14
to
09b34f1
Compare
@GeorgeTsagk, remember to re-request review from reviewers when ready |
ac58e73
to
3163902
Compare
update_add_htlc
remote peer's custom recordsupdate_add_htlc
with remote peer's custom records
3163902
to
ff58154
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ff58154
to
ce2a005
Compare
There was a problem hiding this 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:
- 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)
- Meta/personal preference: move itest to the end of the PR rather than having several iterations of it throughout the code
- 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.
65537: []byte("test"), | ||
}, | ||
} | ||
stream := alice.RPC.SendPayment(sendReq) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
@@ -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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
- HTLC is irrevocably committed on the channel
- Receiving node restarts before forwarding through the switch
- HTLC is restored from disk (no custom records)
- Interceptor receives HTLC without custom records
There was a problem hiding this comment.
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/link.go
Outdated
return err | ||
} | ||
|
||
addMsg.CustomRecords = r |
There was a problem hiding this comment.
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'supdate_add_htlc
addMsg.CustomRecords
are the records that we're going to pack for the outgoing HTLC'supdate_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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 🙏
There was a problem hiding this comment.
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
:')
ce2a005
to
b8cc123
Compare
b8cc123
to
a1677d7
Compare
a1677d7
to
702f860
Compare
@@ -2568,6 +2574,11 @@ func (h *HTLC) serializeExtraData() error { | |||
records = append(records, &b) | |||
}) | |||
|
|||
records, err := h.CustomRecords.ExtendRecordProducers(records) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
htlcswitch/link.go
Outdated
return err | ||
} | ||
|
||
addMsg.CustomRecords = r |
There was a problem hiding this comment.
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.
702f860
to
1b1969b
Compare
There was a problem hiding this 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.
966f41f
into
lightningnetwork:0-19-staging
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 interceptorCloses #8618