multi+server.go: add initial permissions for some peers #9458

Crypt-iQ · 2025-01-29T18:09:53Z

This patch adds initial access permissions in the server for some peers:

If the peer has ever had a channel with us that has confirmed on-chain, they'll be given protected access.
If it has a pending-open channel, it'll be given temporary status.
Otherwise, it'll get restricted status.

In the future, we can tune this criteria. Some of the discovery ban code has also been moved to server.go so that it is somewhat unified.

coderabbitai · 2025-01-29T18:10:01Z

Important

Review skipped

Auto reviews are limited to specific labels.

🏷️ Labels to auto review (1)

llm-review

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>, please review it.
- 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @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.
- @coderabbitai help me debug CodeRabbit configuration file.

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 using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration 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.

bhandras

First shallow pass done, great work! Concept ACK! 🎉 Going to spend some more time with the details. I think in the mean time feel free to reply to my comments with your thoughts/ideas.

bhandras · 2025-01-31T15:15:33Z

channeldb/db.go

+// - The second map denotes the set of nodes that have temporary access to our
+// server. The value denotes the number of pending-open channels that they have
+// with us. If this value gets to 0, their access status will change.
+func (c *ChannelStateDB) FetchPermAndTempPeers(chainHash []byte) (


I suggest refining the return value of this function to make it more general and readable. Rather than categorizing peers as permanent or temporary, we could simply return a single map (map[string]ChanCount) containing the open, pending, and closed channel counts for each peer, where ChanCount is:

struct ChanCount { open int pending int closed int }

If you agree, could you please also add a basic unit test for this function?

I agree that the maps can be merged but I don't think we should track either open or closed counts, there's no point in the current punishment mechanism

brontide/listener.go

bhandras · 2025-01-31T15:30:08Z

brontide/listener.go

+	// is allowed according to our banning heuristic. This is here because
+	// we do not learn the remote node's public static key until we've
+	// received and validated Act 3.
+	remoteKey := brontideConn.RemotePub()


Alternatively, shouldAccept could receive the pubkey and return false if it's nil so we don't need two separate rejection blocks.

Think this is fine as-is, would rather the server not have to take public key pointers

server.go

bhandras · 2025-01-31T16:11:47Z

server.go

@@ -361,6 +411,26 @@ type server struct {
 	// of new blocks.
 	blockbeatDispatcher *chainio.BlockbeatDispatcher

+	// banScoreMtx is used for the server's ban tracking. This should only
+	// be locked after the server mutex has been locked.


Why use an alternative mutex if we already that expect the server mutex is locked?

I'll change the comment, it's meant to convey that if the server mutex is going to be locked, this mutex cannot be locked before the server mutex

Thanks, now clearer.

server.go

bhandras · 2025-01-31T16:23:24Z

server.go

+// NewPendingOpenChan is called after the pending-open channel has been
+// committed to the database. This may transition a restricted-access peer to a
+// temporary-access peer.
+func (s *server) NewPendingOpenChan(remoteHex string) error {


Ideally the ban logic could be separated into its own type altogether and so we could add extensive test coverage through unit tests.

Can you elaborate? Do you mean like a new struct/pkg?

If possible would be nice to decouple the peer banning logic from the server to its own type (struct) so we can cover it with tests separately.

bhandras · 2025-01-31T16:41:18Z

server.go

+
+				// The banScoreMtx cannot be held when the
+				// below DisconnectPeer call occurs.
+				return s.DisconnectPeer(remotePub)


iiuc we could end up demoting more than one peer at the same time.

IIUC when we decrement s.numRestricted when we disconnect and then remove the peer. But the banScoreMtx is lifted in between so it could be that if we reach the ceiling then concurrent calls to this function would still see the same counts. Doesn't seem to be an issue to me, more just a remark.

bhandras · 2025-01-31T16:46:10Z

server.go

+		newStatus := peerSlotStatus{
+			state: protected,
+		}
+		s.peerScores[remoteHex] = newStatus


I don't think we really need the peerScores map either, we can just have a function returning the status based on channel state counts.

prefer to keep as-is for now in case we actually start scoring

bhandras · 2025-01-31T16:49:05Z

server.go

+		s.banScoreMtx.Unlock()
+
+		// This should not be possible.
+		return fmt.Errorf("invalid peer access status")


nit: should we add the status to the error?

It's unreachable code, only added for completeness

bhandras

Looks pretty good! Could you please add an itest covering the added functionality?

bhandras · 2025-02-10T14:25:20Z

server.go

@@ -361,6 +411,26 @@ type server struct {
 	// of new blocks.
 	blockbeatDispatcher *chainio.BlockbeatDispatcher

+	// banScoreMtx is used for the server's ban tracking. This should only
+	// be locked after the server mutex has been locked.


Thanks, now clearer.

bhandras · 2025-02-11T14:04:08Z

channeldb/db.go

@@ -730,6 +731,194 @@ func (c *ChannelStateDB) FetchChannelByID(tx kvdb.RTx, id lnwire.ChannelID) (
 	return c.channelScanner(tx, selector)
 }

+// ChanCount is used by the server in determining access control.
+type ChanCount struct {
+	OpenClosed bool


nit: consider renaming to HasOpenOrClosedChan for better readability. Also please add godocs to these exported fields.

bhandras · 2025-02-11T14:07:27Z

channeldb/db.go

+
+			internalErr := chainBucket.ForEach(func(chanPoint,
+				val []byte) error {
+


I assume we also want to skip non-buckets, so:

// If there's a value, it's not a bucket so ignore it. if v != nil { return nil }

I'll add it. only buckets are stored here though and anybody who is messing with this database structure needs to know what they're doing already and should not be adding key-values here as it would mess up other things

bhandras · 2025-02-11T14:11:19Z

channeldb/db.go

+// ChanCount is used by the server in determining access control.
+type ChanCount struct {
+	OpenClosed bool
+	Pending    uint64


nit: Similarly maybe best to rename to PendingOpenCount for clarity.

bhandras · 2025-02-11T14:16:12Z

channeldb/db.go

+
+			nodeStr := hex.EncodeToString(nodePub)
+
+			count, exists := peerCounts[nodeStr]


Given that we iterate over the openChannelBucket which is keyed by the peer pubkey, the peerCounts map should not have any count for nodeStr. Also the two cases of the below if are exactly the same.

Ah that's right. I wrote the if-else the other way without cases and thought it was confusing for the reader. I'll change this to just insert

bhandras · 2025-02-11T14:21:56Z

channeldb/db_test.go

+	count2, found := peerCounts[pubKeyHex2]
+	require.True(t, found, "unable to find peer 2 in peerCounts")
+	require.False(t, count2.OpenClosed, "found erroneous channels")
+	require.Equal(t, count2.Pending, uint64(1))


nit: expected comes first.

server.go

bhandras · 2025-02-11T14:27:08Z

server.go

+	}
+
+	if shouldDisconnect {
+		return access, ErrGossiperBan


nit: I think it'd be better to explicitly return peerStatusRestricted here and above.

imo doesn't matter, we're returning an error

on second thought, we're dealing with access control so I'll explicitly return

bhandras · 2025-02-11T14:29:42Z

server.go

+// NewPendingOpenChan is called after the pending-open channel has been
+// committed to the database. This may transition a restricted-access peer to a
+// temporary-access peer.
+func (s *server) NewPendingOpenChan(remoteHex string) error {


If possible would be nice to decouple the peer banning logic from the server to its own type (struct) so we can cover it with tests separately.

bhandras · 2025-02-11T14:36:10Z

server.go

+
+				// The banScoreMtx cannot be held when the
+				// below DisconnectPeer call occurs.
+				return s.DisconnectPeer(remotePub)


IIUC when we decrement s.numRestricted when we disconnect and then remove the peer. But the banScoreMtx is lifted in between so it could be that if we reach the ceiling then concurrent calls to this function would still see the same counts. Doesn't seem to be an issue to me, more just a remark.

Crypt-iQ · 2025-02-12T14:59:51Z

I tested the code in a different way and found that the demotion logic for NotifyFundingTimeout only notifies if we are the recipient of a pending channel rather than the initiator. I think this is fine since we have initiated this and the channel potentially could become active as the spec uses a SHOULD for fundee forgetting requirements rather than a MUST.

We introduce a new func FetchPermAndTempPeers that returns two maps. The first map indicates the nodes that will have "protected" access to the server. The second map indicates the nodes that have "temporary" access to the server. This will be used in a future commit in the server.go code.

This signal will be used in the server.go code to potentially demote temporary-access peers to restricted-access peers.

Here we introduce the server caches that will determine the access control status of our peers. Peers that have had their funding transaction confirm with us are protected. Peers that only have pending-open channels with us are temporary access and can have their access revoked. The rest of the peers are granted restricted access. The channelPeers map contains protected-access peers and the pendingChannelPeers map contains temporary-access peers.

This modifies the various channelnotifier notification functions to instead hit the server and then call the notification routine. This allows us to accurately modify the server's maps.

saubyk assigned Crypt-iQ Jan 29, 2025

saubyk added this to the v0.19.0 milestone Jan 29, 2025

saubyk requested review from bhandras and ziggie1984 January 30, 2025 15:27

Crypt-iQ marked this pull request as ready for review January 30, 2025 16:25

bhandras reviewed Jan 31, 2025

View reviewed changes

Crypt-iQ force-pushed the banning_010072025 branch from 77c8555 to cbd7d60 Compare February 4, 2025 18:24

Crypt-iQ requested a review from bhandras February 4, 2025 18:27

Crypt-iQ force-pushed the banning_010072025 branch from cbd7d60 to 15e16ae Compare February 10, 2025 15:14

bhandras reviewed Feb 11, 2025

View reviewed changes

Crypt-iQ force-pushed the banning_010072025 branch 2 times, most recently from bd212b6 to 72ec6df Compare February 13, 2025 18:33

Crypt-iQ added 7 commits February 13, 2025 14:04

channelnotifier: add FundingTimeout and NotifyFundingTimeout

a49ba83

This signal will be used in the server.go code to potentially demote temporary-access peers to restricted-access peers.

funding+server.go: modify notifications to pass through server

3820d40

This modifies the various channelnotifier notification functions to instead hit the server and then call the notification routine. This allows us to accurately modify the server's maps.

itest: new test to check server access perms

0bc636f

sample-lnd.conf: update for num-restricted-slots

b4d7515

release-notes: update for 0.19.0

5a7b753

Crypt-iQ force-pushed the banning_010072025 branch from 72ec6df to 5a7b753 Compare February 13, 2025 19:04


		internalErr := chainBucket.ForEach(func(chanPoint,
		val []byte) error {


		nodeStr := hex.EncodeToString(nodePub)

		count, exists := peerCounts[nodeStr]

multi+server.go: add initial permissions for some peers #9458

Are you sure you want to change the base?

multi+server.go: add initial permissions for some peers #9458

Conversation

Crypt-iQ commented Jan 29, 2025 • edited Loading

coderabbitai bot commented Jan 29, 2025 • edited Loading

Review skipped

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

bhandras left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bhandras left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Crypt-iQ commented Feb 12, 2025

Crypt-iQ commented Jan 29, 2025 •

edited

Loading

coderabbitai bot commented Jan 29, 2025 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)