ChannelCounterparty not instantiable #44

TheBlueMatt · 2021-09-04T00:29:31Z

I'm told you cannot create a ChannelCounterparty object in java, that seems stupid.

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 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

author Tibo-lg <[email protected]> 1631601610 +0900 committer vss96 <[email protected]> 1632205838 +0530 Add node id to custom message callback Update fuzz README with latest instructions Allow multiple monitor_update_failed calls without requiring calls to channel_monitor_updated in between. Found by the fuzzer 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 test utils: refactor fail_payment_along_route for mpp Add MppId field to HTLCSource as a way to correlate mpp payment paths Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received Add all_paths_failed field to PaymentFailed see field docs for details 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. [fuzz] Swap mode on most messages to account for TLV suffix 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. 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. Update docs to specify where process events is called Remove excess whitespace and highlight lightning-net-tokio test utils: refactor fail_payment_along_route for mpp Add MppId field to HTLCSource as a way to correlate mpp payment paths Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received Add all_paths_failed field to PaymentFailed see field docs for details 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. [fuzz] Swap mode on most messages to account for TLV suffix 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. 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. Update docs to specify where process events is called Update docs to specify where process events is called Remove extra whitespace Update fuzz README with latest instructions Allow multiple monitor_update_failed calls without requiring calls to channel_monitor_updated in between. Found by the fuzzer 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 test utils: refactor fail_payment_along_route for mpp Add MppId field to HTLCSource as a way to correlate mpp payment paths Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received Add all_paths_failed field to PaymentFailed see field docs for details 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. [fuzz] Swap mode on most messages to account for TLV suffix 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. 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. Update docs to specify where process events is called

TheBlueMatt added this to the 0.0.101 milestone Sep 4, 2021

TheBlueMatt mentioned this issue Sep 6, 2021

Move CounterpartyForwardingInfo from channel to channelmanager lightningdevkit/rust-lightning#1070

Merged

TheBlueMatt closed this as completed in lightningdevkit/rust-lightning#1070 Sep 17, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ChannelCounterparty not instantiable #44

ChannelCounterparty not instantiable #44

TheBlueMatt commented Sep 4, 2021

ChannelCounterparty not instantiable #44

ChannelCounterparty not instantiable #44

Comments

TheBlueMatt commented Sep 4, 2021