Context
Follow-up to #251
- ldk-node:
056447c28221be02c3d39f8c6ae430a67ebbd850
- rust-lightning:
506cb91f2e0fb87906188b79777bcf42595d3623
1. funding_redeem_script: Option<ScriptBuf>
The witness script locking the funding output to commitment transactions. Useful for anyone
verifying/reconstructing the funding output — e.g. clients doing splice-in with externally
selected UTXOs need this to build the TxOut for the channel's existing funding outpoint
(see lightningdevkit/rust-lightning#4234 for the analogous need on the LDK side).
Proposed: add optional string funding_redeem_script = 33; (hex-encoded) to Channel.
2. counterparty.features: InitFeatures
The feature set our counterparty signaled on last connection (anchor outputs, splicing,
async payments, etc.) — useful for diagnosing why a feature-gated action (e.g. a splice)
fails against a given peer, and for routing-adjacent decisions.
Proposed: add map<uint32, Feature> counterparty_features = 34; to Channel, reusing the
existing Feature { name, is_required } message and features_to_proto() helper already
used for GraphNodeAnnouncement.features — call it with counterparty.features.le_flags()
and a Display-based closure, same pattern as the existing call sites.
Context
Follow-up to #251
056447c28221be02c3d39f8c6ae430a67ebbd850506cb91f2e0fb87906188b79777bcf42595d36231.
funding_redeem_script: Option<ScriptBuf>The witness script locking the funding output to commitment transactions. Useful for anyone
verifying/reconstructing the funding output — e.g. clients doing splice-in with externally
selected UTXOs need this to build the TxOut for the channel's existing funding outpoint
(see lightningdevkit/rust-lightning#4234 for the analogous need on the LDK side).
Proposed: add
optional string funding_redeem_script = 33;(hex-encoded) toChannel.2.
counterparty.features: InitFeaturesThe feature set our counterparty signaled on last connection (anchor outputs, splicing,
async payments, etc.) — useful for diagnosing why a feature-gated action (e.g. a splice)
fails against a given peer, and for routing-adjacent decisions.
Proposed: add
map<uint32, Feature> counterparty_features = 34;toChannel, reusing theexisting
Feature { name, is_required }message andfeatures_to_proto()helper alreadyused for
GraphNodeAnnouncement.features— call it withcounterparty.features.le_flags()and a
Display-based closure, same pattern as the existing call sites.