-
Notifications
You must be signed in to change notification settings - Fork 266
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
[WIP] Random scid #1195
Closed
Closed
[WIP] Random scid #1195
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
to remove old scid from Router and Register mappings without this cleanup those maps may become clogged if new scid is requested often
by BITCOIN_FUNDING_DEEPLYBURIED for private channels
When making an invoice with route hints for private channels: 1. Obtain `List[List[ExtraHop]]` from Router 2. Obtain `Map[ShortChannelId, UsableBalances]` from Relayer 3. Select currently online private channels which can receive an amount
with route hints from private channels
because: - offline channel may still be seen as `enabled=true` by Relayer due to flappy channel protection (channel may go offline without `enabled` updated to `false`). - online channel may still be seen as `enabled=false` by Relayer because incoming channels are initially below reserve so can't send but can receive. Using new approach an API user may apply additional logic to output: - for sending: throw away all channels with `enabled=false`, offline and `enabled=true` may happen but that's not a serious issue (sender will retry with different route). - for receiving: keep all `enabled=false` because they may be online but below reserve (perfectly good for receiving) or offline (but may become online by the time a payment arrives).
and check if local balance has changed in Auditor, this lets Relayer always know an actual sendable/receivable for every channel
They're 114/115 currently (did not figure out how to make those work), but will be 14/15 once PR is merged: lightning/bolts#681 (comment)
`-- excludeIsolatedPeers = true`: do not use route hints for private channels with remote peers who are themselves not announced on network (to exclude mobile LN nodes which do not announce themselves and only use private channels, routing hints from those are useless). `-- vertexThreshold=3`: do not use route hints for private channels with remote peers who did announce themselves but have less than 3 public channels because chances of routing success from those are low.
I think we can close this PR as rusty decided to retract the corresponding spec PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's an attempt to implement lightning/bolts#681, it is sufficient for my needs as is but not complete and overall has different goals mixed in, maybe parts of it will be of help.
What is does:
scid
basics: feature bits, messages, assigning logic500000
scid
is used for both sides of channel which is probably not compliant (option_scid_assign: privacy protection for private channels. lightning/bolts#681 (comment)) but makes implementation easy (Router
first receivesLocalChannelUpdate
and then remotePeerRoutingMessage
with a same randomscid
)ChannelUpdate
s after assigning randomscid
to make sureRouter
has a refreshedPrivateChannel
with both updates present.UsableBalances
logic inRelayer
, see https://gitter.im/ACINQ/developers?at=5db6cec8e886fb5aa20d6776 and https://gitter.im/ACINQ/developers?at=5db9756c14d55a3785a12f2bcreateinvoicewithextrahops
API call which was a goal for all of this. This call creates an invoice with routing hints for local private channels which can receive a requested amount right now (have remoteChannelUpdate
, have sufficientavailableBalanceForReceive
).