-
Notifications
You must be signed in to change notification settings - Fork 377
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
Fix typos #2
Merged
Merged
Fix typos #2
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
ariard
pushed a commit
to ariard/rust-lightning
that referenced
this pull request
Jun 9, 2018
jeandudey
added a commit
to jeandudey/rust-lightning
that referenced
this pull request
Jun 30, 2018
This constants defines the maximum value of `open_channel.funding_satoshis`, currently it's defined to be 2^24 according to the BOLT lightningdevkit#2 specification. Also a test was added to check that the constant is never over 2,1x10^15 (maximum satoshis in bitcoin) if modified. Signed-off-by: Jean Pierre Dudey <[email protected]>
jeandudey
added a commit
to jeandudey/rust-lightning
that referenced
this pull request
Jun 30, 2018
This constants defines the maximum value of `open_channel.funding_satoshis`, currently it's defined to be 2^24 according to the BOLT lightningdevkit#2 specification. Also a test was added to check that the constant is never over 2,1x10^15 (maximum satoshis in bitcoin) if modified. Signed-off-by: Jean Pierre Dudey <[email protected]>
jeandudey
added a commit
to jeandudey/rust-lightning
that referenced
this pull request
Jun 30, 2018
This constants defines the maximum value of `open_channel.funding_satoshis`, currently it's defined to be 2^24 according to the BOLT lightningdevkit#2 specification. Also a test was added to check that the constant is never over 2,1x10^15 (maximum satoshis in bitcoin) if modified. Signed-off-by: Jean Pierre Dudey <[email protected]>
jeandudey
added a commit
to jeandudey/rust-lightning
that referenced
this pull request
Jun 30, 2018
This constants defines the maximum value of `open_channel.funding_satoshis`, currently it's defined to be 2^24 according to the BOLT lightningdevkit#2 specification. Also a test was added to check that the constant is never over 2,1x10^15 (maximum satoshis in bitcoin) if modified. Signed-off-by: Jean Pierre Dudey <[email protected]>
yuntai
added a commit
to yuntai/rust-lightning
that referenced
this pull request
Aug 29, 2018
Per Bolt lightningdevkit#2, both your_last_per_commitment_secret & my_current_per_commitment_point are optional depending on `data_loss_protect`
ariard
pushed a commit
to ariard/rust-lightning
that referenced
this pull request
Mar 11, 2020
vss96
referenced
this pull request
in vss96/rust-lightning
Sep 21, 2021
# This is the 1st commit message: test utils: refactor fail_payment_along_route for mpp # This is the commit message #2: Add MppId field to HTLCSource as a way to correlate mpp payment paths # This is the commit message #3: Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage # This is the commit message #4: Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits # This is the commit message #5: Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received # This is the commit message #6: Add all_paths_failed field to PaymentFailed see field docs for details # This is the commit message #7: Drop writer size hinting/message vec preallocation In order to avoid significant malloc traffic, messages previously explicitly stated their serialized length allowing for Vec preallocation during the message serialization pipeline. This added some amount of complexity in the serialization code, but did avoid some realloc() calls. Instead, here, we drop all the complexity in favor of a fixed 2KiB buffer for all message serialization. This should not only be simpler with a similar reduction in realloc() traffic, but also may reduce heap fragmentation by allocating identically-sized buffers more often. # This is the commit message #8: [fuzz] Swap mode on most messages to account for TLV suffix # This is the commit message #9: Add forward-compat due serialization variants of HTLCFailureMsg Going forward, all lightning messages have a TLV stream suffix, allowing new fields to be added as needed. In the P2P protocol, messages have an explicit length, so there is no implied length in the TLV stream itself. HTLCFailureMsg enum variants have messages in them, but without a size prefix or any explicit end. Thus, if a HTLCFailureMsg is read as a part of a ChannelManager, with a TLV stream at the end, there is no way to differentiate between the end of the message and the next field(s) in the ChannelManager. Here we add two new variant values for HTLCFailureMsg variants in the read path, allowing us to switch to the new values if/when we add new TLV fields in UpdateFailHTLC or UpdateFailMalformedHTLC so that older versions can still read the new TLV fields. # This is the commit message #10: Convert most P2P msg serialization to a new macro with TLV suffixes The network serialization format for all messages was changed some time ago to include a TLV suffix for all messages, however we never bothered to implement it as there isn't a lot of use validating a TLV stream with nothing to do with it. However, messages are increasingly utilizing the TLV suffix feature, and there are some compatibility concerns with messages written as a part of other structs having their format changed (see previous commit). Thus, here we go ahead and convert most message serialization to a new macro which includes a TLV suffix after a series of fields, simplifying several serialization implementations in the process. # This is the commit message #11: Update docs to specify where process events is called
vss96
referenced
this pull request
in vss96/rust-lightning
Sep 21, 2021
# This is the 1st commit message: Update fuzz README with latest instructions # This is the commit message #2: Allow multiple monitor_update_failed calls without requiring calls to channel_monitor_updated in between. Found by the fuzzer # This is the commit message #3: Move CounterpartyForwardingInfo from channel to channelmanager CounterpartyForwardingInfo is public (previously exposed with a `pub use`), and used inside of ChannelCounterparty in channelmanager.rs. However, it is defined in channel.rs, away from where it is used. This would be fine, except that the bindings generator is somewhat confused by this - it doesn't currently support interpreting `pub use` as a struct to expose, instead ignoring it. Fixes lightningdevkit/ldk-garbagecollected#44 # This is the commit message #4: test utils: refactor fail_payment_along_route for mpp # This is the commit message #5: Add MppId field to HTLCSource as a way to correlate mpp payment paths # This is the commit message #6: Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage # This is the commit message #7: Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits # This is the commit message #8: Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received # This is the commit message #9: Add all_paths_failed field to PaymentFailed see field docs for details # This is the commit message #10: Drop writer size hinting/message vec preallocation In order to avoid significant malloc traffic, messages previously explicitly stated their serialized length allowing for Vec preallocation during the message serialization pipeline. This added some amount of complexity in the serialization code, but did avoid some realloc() calls. Instead, here, we drop all the complexity in favor of a fixed 2KiB buffer for all message serialization. This should not only be simpler with a similar reduction in realloc() traffic, but also may reduce heap fragmentation by allocating identically-sized buffers more often. # This is the commit message #11: [fuzz] Swap mode on most messages to account for TLV suffix # This is the commit message #12: Add forward-compat due serialization variants of HTLCFailureMsg Going forward, all lightning messages have a TLV stream suffix, allowing new fields to be added as needed. In the P2P protocol, messages have an explicit length, so there is no implied length in the TLV stream itself. HTLCFailureMsg enum variants have messages in them, but without a size prefix or any explicit end. Thus, if a HTLCFailureMsg is read as a part of a ChannelManager, with a TLV stream at the end, there is no way to differentiate between the end of the message and the next field(s) in the ChannelManager. Here we add two new variant values for HTLCFailureMsg variants in the read path, allowing us to switch to the new values if/when we add new TLV fields in UpdateFailHTLC or UpdateFailMalformedHTLC so that older versions can still read the new TLV fields. # This is the commit message #13: Convert most P2P msg serialization to a new macro with TLV suffixes The network serialization format for all messages was changed some time ago to include a TLV suffix for all messages, however we never bothered to implement it as there isn't a lot of use validating a TLV stream with nothing to do with it. However, messages are increasingly utilizing the TLV suffix feature, and there are some compatibility concerns with messages written as a part of other structs having their format changed (see previous commit). Thus, here we go ahead and convert most message serialization to a new macro which includes a TLV suffix after a series of fields, simplifying several serialization implementations in the process. # This is the commit message #14: Update docs to specify where process events is called
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.
Fix typos.