Uh oh!
There was an error while loading. Please reload this page.
Include counterpart_node_id in TransactionType - #4393
Conversation
👋 Thanks for assigning @wpaulino as a reviewer! |
| if let Some(channel_id) = output_info.channel_id { | ||
| if !channel_ids.contains(&channel_id) { | ||
| channel_ids.push(channel_id); | ||
| if let (Some(counterparty_node_id), Some(channel_id)) = |
There was a problem hiding this comment.
Want to point out that this will result in an empty channels for already-tracked entries on upgrade. We'll need to see how to handle that case downstream I guess. Technically we'd need to make the tracking an Option<PublicKey> but that's just odd.
This adds an optional `counterparty_node_id` field to the `SpendableOutputs` event, providing users with information about which channel counterparty the spendable outputs belong to. The field uses TLV type 3 (odd) for backwards compatibility, meaning older versions will safely ignore it during deserialization. When reading events serialized by older LDK versions, this field will be `None`. Co-Authored-By: HAL 9000 Signed-off-by: Elias Rohrer <dev@tnull.de>
This adds an optional `counterparty_node_id` field to `TrackedSpendableOutput` and updates the `track_spendable_outputs` method signatures on both `OutputSweeper` and `OutputSweeperSync` to accept this new parameter. The field uses TLV type 3 (odd) for backwards compatibility. When reading outputs tracked with LDK 0.2 and prior, this field will be `None`. Co-Authored-By: HAL 9000 Signed-off-by: Elias Rohrer <dev@tnull.de>
This adds `counterparty_node_id` tracking to all `TransactionType` variants, enabling downstream users to identify the channel counterparty associated with each broadcast transaction. For single-channel variants (`CooperativeClose`, `UnilateralClose`, `AnchorBump`, `Claim`, `Splice`), the counterparty is stored directly. For multi-channel variants (`Funding`, `Sweep`), the type now uses `Vec<(PublicKey, ChannelId)>` to pair each channel with its counterparty. The `OnchainTxHandler` now stores `counterparty_node_id` and provides a `set_counterparty_node_id` method for initialization during deserialization of older data. Co-Authored-By: HAL 9000 Signed-off-by: Elias Rohrer <dev@tnull.de>
ad4cc6c to
56f12c8Compare| .list_channels() | ||
| .into_iter() | ||
| .any(|cd| cd.channel_id == ch_id && cd.is_channel_ready); | ||
| .find(|cd| cd.channel_id == ch_id && cd.is_channel_ready); |
There was a problem hiding this comment.
might make sense to filter by UCID here as well. Technically channel id isn't unique for 0confs even if is_channel_ready.
Uh oh!
There was an error while loading. Please reload this page.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #4393 +/- ##
==========================================
- Coverage 86.04% 86.02% -0.02%
==========================================
Files 156 156 Lines 103002 103046 +44 Branches 103002 103046 +44 ==========================================
+ Hits 88627 88646 +19 - Misses 11865 11888 +23 - Partials 2510 2512 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Closes#4391
In #4353 we added a
TransactionTypethat also indicated theChannelIds associated with the broadcasted transaction. However, as pointed out there,ChannelIds might are always just guranteed to be unique on a per-counterparty basis.Therefore, we here track the
counterparty_node_idside-by-side with theChannelId, which notably also requires to track it as part ofEvent::SpendableOutputs and inOutputSweeper.