multi: enable max htlc update #3523
Conversation
joostjager
requested review from
cfromknecht,
halseth,
Roasbeef and
wpaulino
as code owners
joostjager
force-pushed
the
enable-update-max-htlc
branch
4 times, most recently
from
f29e2e1
to
e1d86d0
Compare
joostjager
added
enhancement
joostjager
force-pushed
the
enable-update-max-htlc
branch
2 times, most recently
from
8b0c83c
to
494bd2b
Compare
routing/localchans/manager.go
Outdated
| if !edge.MessageFlags.HasMaxHtlc() { | ||
| return fmt.Errorf("channel %v has no max htlc", | ||
| info.ChannelPoint) | ||
| } |
There was a problem hiding this comment.
Not sure about this sanity check. I actually don't like sanity checks.
There was a problem hiding this comment.
This assumes an order that the gossiper always runs before this is called, so I think it is safest to keep the check?
There was a problem hiding this comment.
Removed those changes from the pr. It is more complicated, because the gossiper migrates the updates in the background.
joostjager
force-pushed
the
enable-update-max-htlc
branch
from
494bd2b
to
0d5a2c5
Compare
routing/localchans/manager.go
Outdated
| if !edge.MessageFlags.HasMaxHtlc() { | ||
| return fmt.Errorf("channel %v has no max htlc", | ||
| info.ChannelPoint) | ||
| } |
There was a problem hiding this comment.
This assumes an order that the gossiper always runs before this is called, so I think it is safest to keep the check?
| @@ -1211,6 +1218,14 @@ func (d *AuthenticatedGossiper) retransmitStaleAnns(now time.Time) error { | |||
| // introduction of the MaxHTLC field, then we'll update this | |||
| // edge to propagate this information in the network. | |||
| if !edge.MessageFlags.HasMaxHtlc() { | |||
| // We'll make sure we support the new max_htlc field if | |||
There was a problem hiding this comment.
maybe we should move this check/update to the local manager instead? Making gossiper as unaware of local changes as possible,
There was a problem hiding this comment.
I wanted to keep the change set small. Moving retransmission of stale channels to the local chan mgr is a much larger change. Also not sure if that is the place where it belongs.
There was a problem hiding this comment.
I think that's the direction we should move in, but agree that's a much larger change that shouldn't be done in this PR.
joostjager
force-pushed
the
enable-update-max-htlc
branch
3 times, most recently
from
6858af0
to
3be4344
Compare
joostjager
force-pushed
the
enable-update-max-htlc
branch
3 times, most recently
from
35b3338
to
6102618
Compare
joostjager
force-pushed
the
enable-update-max-htlc
branch
4 times, most recently
from
15e88aa
to
1e68d76
Compare
| @@ -1211,6 +1218,14 @@ func (d *AuthenticatedGossiper) retransmitStaleAnns(now time.Time) error { | |||
| // introduction of the MaxHTLC field, then we'll update this | |||
| // edge to propagate this information in the network. | |||
| if !edge.MessageFlags.HasMaxHtlc() { | |||
| // We'll make sure we support the new max_htlc field if | |||
There was a problem hiding this comment.
I think that's the direction we should move in, but agree that's a much larger change that shouldn't be done in this PR.
| } | ||
|
|
||
| // Apply the new policy to the edge. | ||
| err := r.updateEdge(info.ChannelPoint, edge, newSchema) |
There was a problem hiding this comment.
This is a bit strange, since the updated edge policy is invalid after this call (it hasn't been re-signed). A more natural split would be for the localChanManager to fully update and re-sign the policies, and then for the gossiper to just forward them around as any other network update. but maybe that's a change too big for this PR.
There was a problem hiding this comment.
Summary from offline discussion:
- Ideally gossiper would just gossip and not sign.
- In an
lndmode of operation where there is no gossip (all is private), there wouldn't be a need for signatures on local updates. Signing inlocalchans.Managerwouldn't be necessary either. - An interconnecting component that takes policies from
localchans.Managerand resigns them when they change or become stale could be a solution.
To keep the scope of this pr under control, I only added a call to clear the signature in localchans.Manager.
The signature is retrieved, not used and overwritten with a new signature.
As a preparation for making the gossiper less responsible for validating and supplementing local channel policy updates, this commits moves the on-the-fly max htlc migration up the call tree. The plan for a follow up commit is to move it out of the gossiper completely for local channel updates, so that we don't need to return a list of final applied policies anymore.
The policy update logic that resided part in the gossiper and part in the rpc server is extracted into its own object. This prepares for additional validation logic to be added for policy updates that would otherwise make the gossiper heavier. It is also a small first step towards separation of our own channel data from the rest of the graph.
In this commit, we update the router and link to support users updating the max HTLC policy for their channels. By updating these internal systems before updating the RPC server and lncli, we protect users from being shown an option that doesn't actually work.
In this commit, we enable callers of UpdateChannelPolicy to specify their desired max HTLC forwarding policy for one or multiple channels.
In this commit, we enable callers of UpdateChannelPolicy to specify their desired max HTLC forwarding policy for one or multiple channels over lncli.
joostjager
force-pushed
the
enable-update-max-htlc
branch
from
1e68d76
to
5aefe8b
Compare
wpaulino
requested review from
Roasbeef
and removed request for
Roasbeef and
wpaulino
In this PR, we enable users to update the max HTLC for a given channel or channels.
Rewrite of #2438