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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi: accept memo note when opening channel #7668

Merged
merged 9 commits into from May 19, 2023

Conversation

shaurya947
Copy link
Contributor

@shaurya947 shaurya947 commented May 4, 2023

Change Description

Fixes #7639 by allowing a note ("memo") to go along with channel creation when using the openchannel CLI/RPC/JSON command. We accept a string with max length of 500 (command is rejected if length is exceeded) and persist it in a hex-encoded format as part of the TLV stream. When channels are queried, we retrieve the value and decode it before passing the info to the caller. We also add a new itest to verify both the happy and unhappy path.

Steps to Test

When using openchannel through CLI/RPC/JSON, pass in a memo note using the memo argument. If length is valid (<= 500), it should persist and be retrievable in listchannels call. If length is invalid, the command should be rejected with an appropriate error message.

Pull Request Checklist

Testing

  • Your PR passes all CI checks.
  • Tests covering the positive and negative (error paths) are included.
  • Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

馃摑 Please see our Contribution Guidelines for further guidance.

@shaurya947
Copy link
Contributor Author

shaurya947 commented May 5, 2023

Looks like TestFetchHistoricalChannel is failing inside db_test.go and I'm not quite sure why. It fails when deep-comparing channel with histChannel:

if !reflect.DeepEqual(histChannel, channel) {

The test seems to pass if I attach a Memo here:

return &OpenChannel{

But that shouldn't be required right? Am I doing something wrong with the TLV stream which messes up (de)serialization when the Memo field is not present?

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.

Very nice feature and well structured PR, thanks a lot!

rpcserver.go Outdated Show resolved Hide resolved
channeldb/channel.go Show resolved Hide resolved
channeldb/channel.go Outdated Show resolved Hide resolved
lnrpc/lightning.proto Show resolved Hide resolved
rpcserver.go Outdated Show resolved Hide resolved
itest/list_on_test.go Outdated Show resolved Hide resolved
itest/lnd_open_channel_test.go Outdated Show resolved Hide resolved
@shaurya947
Copy link
Contributor Author

Hey @guggero I updated the PR to address all your feedback:

  • Ditch hex encoding
  • Combine dbchannel changes into a single commit
  • Combine lnrpc changes into a single commit
  • Reuse existing itest

Also thanks so much for helping with the unit test failure. Your suggestion seems to have worked 馃檪

@guggero guggero self-requested a review May 11, 2023 20:58
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.

Just a couple of more nits, otherwise LGTM 馃帀

cmd/lncli/cmd_open_channel.go Show resolved Hide resolved
itest/lnd_open_channel_test.go Outdated Show resolved Hide resolved
@shaurya947
Copy link
Contributor Author

Hey @guggero addressed all your feedback as well as fixed a silly mistake I made in the itest (used ht.Alice/ht.Bob instead of the alice and bob arguments)

@guggero guggero requested a review from Crypt-iQ May 15, 2023 08:35
@Crypt-iQ Crypt-iQ removed their request for review May 15, 2023 14:10
@shaurya947
Copy link
Contributor Author

Hey @guggero the windows itest check seems to fail because of a process lock on a file it seems? Is that expected?

Also any suggestions as to whom I could tag for a second review?

@guggero
Copy link
Collaborator

guggero commented May 17, 2023

Hey @guggero the windows itest check seems to fail because of a process lock on a file it seems? Is that expected?

Yeah, unfortunately some itests are still flaky, we are working on that.

Also any suggestions as to whom I could tag for a second review?

Good question. Looking for volunteers, @ffranr, @positiveblue, @sputn1ck, @bitromortac.

@ffranr ffranr self-requested a review May 17, 2023 14:57
Copy link
Collaborator

@positiveblue positiveblue left a comment

Choose a reason for hiding this comment

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

LGTM 馃殌

This is such a quick win. I can see a lot of usage form external software that opens channels automatically for example.

I think we should make the UX more coherent by also adding this field to the PendingChannels proto message but nothing blocking.

rpcserver.go Outdated
@@ -2169,6 +2169,11 @@ func (r *rpcServer) parseOpenChannelReq(in *lnrpc.OpenChannelRequest,
in.CommitmentType)
}

if len(in.Memo) > 500 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: create a constant for this magic number

Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: consider adding a comment to explain why the length needs to be limited to 500.

useful information. This is only ever stored locally and in no way impacts
the channel's operation.
*/
string memo = 36;
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: we should add the same field to PendingChannels

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will address in a follow-up PR if that's ok. Want to make sure I can handle all cases around pendingopen/pendingforceclose/pendingwaitingclose properly and not inadvertently cause any more regressions in this PR.

lnrpc/lightning.proto Show resolved Hide resolved
Copy link
Collaborator

@ffranr ffranr left a comment

Choose a reason for hiding this comment

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

I enjoyed walking through the commits, nice work!

rpcserver.go Outdated
@@ -2169,6 +2169,11 @@ func (r *rpcServer) parseOpenChannelReq(in *lnrpc.OpenChannelRequest,
in.CommitmentType)
}

if len(in.Memo) > 500 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: consider adding a comment to explain why the length needs to be limited to 500.

Comment on lines +395 to +397
// Bob shouldn't see the memo since it's for Alice only.
channel = ht.QueryChannelByChanPoint(bob, chanPoints[0])
require.Empty(ht, channel.Memo, "Memo is not empty")
Copy link
Collaborator

Choose a reason for hiding this comment

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

馃憤

This commit adds the memo field to the protobuf message and generates
the new go files.
This commit simply adds a new memo flag to the openchannel command.
Memo could be any note-to-self kind of useful information to go
along with the channel. The value isn't used yet, will be in the
next commit.
@shaurya947
Copy link
Contributor Author

Thanks for the review @positiveblue and @ffranr ! 馃檪

I fixed the one commit message and created a constant for the magic number (along with some comments). I will defer the PendingChannels change for a follow-up PR if that's ok. I've made a branch for it, I just want to make sure I can handle all the different pending states properly and not cause any more inadvertent regressions in this PR.

In this commit we ensure that the string length of the memo field
specified as part of the OpenChannelRequest is no longer than 500.
We add byte-array field called Memo to the InitFundingMsg struct.
We also provide a value for this from
rpcserver.go#parseOpenChannelReq().
We also pass the value of Memo from funding/manager.go.
We add a Memo field to the OpenChannel DB struct. We also persist
it using a tlv record. We then pass the Memo value from the
InitFundingReserveMsg when creating a new reservation for the channel.
Finally, we also read Memo field when fetching channel from DB.
This allows us the memo to be returned in responses such as
listchannels.
We test both the happy path (valid memo is returned when querying),
as well as the unhappy path (invalid memo rejects the open action).
To accomplish this, we update the OpenChannelParams struct inside
the harness to accept the Memo.
Copy link
Collaborator

@ffranr ffranr left a comment

Choose a reason for hiding this comment

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

Looks good to me! Detailed commit messages 馃憤

Note that I haven't tested.

@guggero guggero merged commit ac3e7be into lightningnetwork:master May 19, 2023
20 of 24 checks passed
@shaurya947
Copy link
Contributor Author

Thank you folks! My first PR 馃ゲ

@shaurya947 shaurya947 deleted the open-channel-memo branch May 24, 2023 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
channels rpc Related to the RPC interface
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[feature]: allow user-specified label when opening channels
5 participants