You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# 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
0 commit comments