Skip to content
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 1 commit into from
Feb 28, 2018
Merged

Fix typos #2

merged 1 commit into from
Feb 28, 2018

Conversation

practicalswift
Copy link
Contributor

Fix typos.

@TheBlueMatt TheBlueMatt merged commit f2eadb0 into lightningdevkit:master Feb 28, 2018
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants