-
Notifications
You must be signed in to change notification settings - Fork 265
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
Add private flag to channel updates #2362
Merged
Merged
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
t-bast
force-pushed
the
channel-update-no-forward-flag
branch
2 times, most recently
from
August 4, 2022 08:15
b369ce4
to
da27f16
Compare
Codecov Report
@@ Coverage Diff @@
## master #2362 +/- ##
==========================================
+ Coverage 84.82% 84.94% +0.11%
==========================================
Files 198 198
Lines 15761 15812 +51
Branches 655 711 +56
==========================================
+ Hits 13369 13431 +62
+ Misses 2392 2381 -11
|
t-bast
force-pushed
the
channel-update-no-forward-flag
branch
from
August 8, 2022 13:13
da27f16
to
ddf5b53
Compare
Add a message flag to channel update to specify that an update is private and should not be rebroadcast to other nodes. We log an error if a private channel update gets into the rebroadcast list. See lightning/bolts#999
t-bast
force-pushed
the
channel-update-no-forward-flag
branch
from
September 27, 2022 07:40
ddf5b53
to
cbd3bbd
Compare
Merged
pm47
reviewed
Nov 4, 2022
eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/LightningMessageTypes.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/LightningMessageCodecs.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/FailureMessage.scala
Show resolved
Hide resolved
eclair-core/src/test/resources/nonreg/codecs/000003-DATA_NORMAL/fundee-announced/data.json
Outdated
Show resolved
Hide resolved
pm47
previously approved these changes
Nov 4, 2022
pm47
approved these changes
Nov 4, 2022
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.
Add a message flag to channel update to specify that an update is private and should not be rebroadcast to other nodes.
We log an error if a private channel update gets into the rebroadcast list.
I also tried strongly typing channel updates, dividing them into
PrivateChannelUpdate
andPublicChannelUpdate
to get compile-time guarantees that private channel updates wouldn't leak where they're not supposed to, but unfortunately I hit some roadblocks...the main issue with this approach is that we would needRouter.PublicChannel
andRouter.PrivateChannel
to map to these two types of channel updates, but that's not how we use them internally: when a public channel isn't confirmed yet, we store it as a private channel which messes things up. Ideally we would need to rework this to clearly separate channels that will be public once confirmed from channels that will stay private, but that's quite a lot of work for not much benefits, so I'm leaving it aside for now.cln has already merged support for this on their
master
branch, and I have successfully tested interop with them.See lightning/bolts#999