Skip to content

Follow-ups to #2688#2791

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.

Sign up for GitHub

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

Merged
TheBlueMatt merged 7 commits into from
Jan 11, 2024
Merged

Follow-ups to #2688 #2791

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
2917666
DRY Channel::fail_htlc handling on holding cell free.
valentinewallace Dec 13, 2023
d0d1634
Clean up code DRY'd in previous commit.
valentinewallace Jan 10, 2024
5c880a0
Fix logger usage during batched htlc processing of malforms.
valentinewallace Dec 13, 2023
04e70ba
DRY malformed HTLC handling during htlc batch processing.
valentinewallace Dec 13, 2023
95b3ef4
Normalize order of (sha256_of_onion, failure_code) in trait.
valentinewallace Dec 13, 2023
c1fbb90
Remove outdated comment.
valentinewallace Dec 13, 2023
3ec4d52
Rename parameter from err_packet to err_contents.
valentinewallace Dec 13, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 37 additions & 45 deletions lightning/src/ln/channel.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
}
}
impl FailHTLCContents for (u16, [u8; 32]) {
type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
type Message = msgs::UpdateFailMalformedHTLC;
fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
msgs::UpdateFailMalformedHTLC {
htlc_id,
channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
Comment on lines +2552 to +2553

@shaavanshaavanDec 19, 2023

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.

In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.

write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});

And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.

@TheBlueMattTheBlueMattJan 9, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.

}
}
fn to_inbound_htlc_state(self) -> InboundHTLCState {
InboundHTLCState::LocalRemoved(
InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
)
InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
}
fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
HTLCUpdateAwaitingACK::FailMalformedHTLC {
htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
}
}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
pub fn queue_fail_malformed_htlc<L: Deref>(
&mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
) -> Result<(), ChannelError> where L::Target: Logger {
self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
.map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
/// [`ChannelError::Ignore`].
fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
&mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
&mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
logger: &L
) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
}
}
log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
return Ok(None);
}

log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
E::Message::name(), &self.context.channel_id());
{
let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
htlc.state = err_packet.clone().to_inbound_htlc_state();
htlc.state = err_contents.clone().to_inbound_htlc_state();
}

Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
}

// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
// the limit. In case it's less rare than I anticipate, we may want to revisit
// handling this case better and maybe fulfilling some of the HTLCs while attempting
// to rebalance channels.
match &htlc_update {
let fail_htlc_res = match &htlc_update {
&HTLCUpdateAwaitingACK::AddHTLC {
amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
}
}
}
None
},
&HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
// If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
{ monitor_update } else { unreachable!() };
update_fulfill_count += 1;
monitor_update.updates.append(&mut additional_monitor_update.updates);
None
},
&HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
Ok(update_fail_msg_option) => {
// If an HTLC failure was previously added to the holding cell (via
// `queue_fail_htlc`) then generating the fail message itself must
// not fail - we should never end up in a state where we double-fail
// an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
// for a full revocation before failing.
debug_assert!(update_fail_msg_option.is_some());
update_fail_count += 1;
},
Err(e) => {
if let ChannelError::Ignore(_) = e {}
else {
panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
}
}
}
Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
.map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
},
&HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
Ok(update_fail_malformed_opt) => {
debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
update_fail_count += 1;
},
Err(e) => {
if let ChannelError::Ignore(_) = e {}
else {
panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
}
}
}
},
Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
.map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
}
};
if let Some(res) = fail_htlc_res {
match res {
Ok(fail_msg_opt) => {
// If an HTLC failure was previously added to the holding cell (via
// `queue_fail_{malformed_}htlc`) then generating the fail message itself must
// not fail - we should never end up in a state where we double-fail
// an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
// for a full revocation before failing.
debug_assert!(fail_msg_opt.is_some());
update_fail_count += 1;
},
Err(ChannelError::Ignore(_)) => {},
Err(_) => {
panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
},
}
}
}
if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down
47 changes: 21 additions & 26 deletions lightning/src/ln/channelmanager.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
let logger = WithChannelContext::from(&self.logger, &chan.context);
for forward_info in pending_forwards.drain(..) {
match forward_info {
let queue_fail_htlc_res = match forward_info {
HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
));
continue;
}
None
},
HTLCForwardInfo::AddHTLC { .. } => {
panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
},
HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
if let Err(e) = chan.queue_fail_htlc(
htlc_id, err_packet, &&logger
) {
if let ChannelError::Ignore(msg) = e {
log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
} else {
panic!("Stated return value requirements in queue_fail_htlc() were not met");
}
// fail-backs are best-effort, we probably already have one
// pending, and if not that's OK, if not, the channel is on
// the chain and sending the HTLC-Timeout is their problem.
continue;
}
Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
},
HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
if let ChannelError::Ignore(msg) = e {
log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
} else {
panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
}
// fail-backs are best-effort, we probably already have one
// pending, and if not that's OK, if not, the channel is on
// the chain and sending the HTLC-Timeout is their problem.
continue;
}
log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
let res = chan.queue_fail_malformed_htlc(
htlc_id, failure_code, sha256_of_onion, &&logger
);
Some((res, htlc_id))

@vladimirfomenevladimirfomeneJan 10, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?

@valentinewallacevalentinewallaceJan 10, 2024

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400

},
};
if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
if let Err(e) = queue_fail_htlc_res {
if let ChannelError::Ignore(msg) = e {
log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
} else {
panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");

@shaavanshaavanDec 19, 2023

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!

But we are also combining the panic messages that can be generated from two different sources here.
Would this be an optimal thing to do?

@TheBlueMattTheBlueMattJan 9, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.

}
// fail-backs are best-effort, we probably already have one
// pending, and if not that's OK, if not, the channel is on
// the chain and sending the HTLC-Timeout is their problem.
continue;
}
}
}
} else {
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
Follow-ups to #2688 by valentinewallace · Pull Request #2791 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #2688#2791

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.

 Sign up for GitHub

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

 Merged

TheBlueMatt
merged 7 commits into

from

Jan 11, 2024
 Merged


Follow-ups to #2688
#2791
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


7 commits


Select commit
Hold shift + click to select a range
2917666

DRY Channel::fail_htlc handling on holding cell free.


valentinewallace Dec 13, 2023
d0d1634

Clean up code DRY'd in previous commit.


valentinewallace Jan 10, 2024
5c880a0

Fix logger usage during batched htlc processing of malforms.


valentinewallace Dec 13, 2023
04e70ba

DRY malformed HTLC handling during htlc batch processing.


valentinewallace Dec 13, 2023
95b3ef4

Normalize order of (sha256_of_onion, failure_code) in trait.


valentinewallace Dec 13, 2023
c1fbb90

Remove outdated comment.


valentinewallace Dec 13, 2023
3ec4d52

Rename parameter from err_packet to err_contents.


valentinewallace Dec 13, 2023

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


82 changes: 37 additions & 45 deletions
lightning/src/ln/channel.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2543,26 +2543,24 @@ impl FailHTLCContents for msgs::OnionErrorPacket {
 HTLCUpdateAwaitingACK::FailHTLC { htlc_id, err_packet: self }
	}
}
impl FailHTLCContents for (u16, [u8; 32]) {
	type Message = msgs::UpdateFailMalformedHTLC; // (failure_code, sha256_of_onion)
impl FailHTLCContents for ([u8; 32], u16) {
	type Message = msgs::UpdateFailMalformedHTLC;
	fn to_message(self, htlc_id: u64, channel_id: ChannelId) -> Self::Message {
 msgs::UpdateFailMalformedHTLC {
 htlc_id,
 channel_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1

Comment on lines

+2552
 to 
+2553

@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revert this change.
In the reading and writing of tlvs, sha256_of_onion is followed by failure_code.
write_tlv_fields!(w,{(0, htlc_id, required),(1, failure_code, required),(2, dummy_err_packet, required),(3, sha256_of_onion, required),});
And if we want to prevent tuple destructing, I think we should follow tlvs order in the rest of the codebase.
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree with you, we should have gone with (failure_code, sha256) rather than the opposite, but sadly we can't (easily) change the InboundHTLCRemovalReason serialization at this point, and IMO we should prefer to match our existing order everywhere rather than have a different order here. Its not all that critical in any direction, of course, though, we're talking about moving around 32+2 bytes.
 }
	}
	fn to_inbound_htlc_state(self) -> InboundHTLCState {
 InboundHTLCState::LocalRemoved(
 InboundHTLCRemovalReason::FailMalformed((self.1, self.0))
 )
 InboundHTLCState::LocalRemoved(InboundHTLCRemovalReason::FailMalformed(self))
	}
	fn to_htlc_update_awaiting_ack(self, htlc_id: u64) -> HTLCUpdateAwaitingACK {
 HTLCUpdateAwaitingACK::FailMalformedHTLC {
 htlc_id,
failure_code: self.0,
sha256_of_onion: self.1
sha256_of_onion: self.0,
failure_code: self.1
 }
	}
}
Expand DownExpand Up@@ -2888,7 +2886,7 @@ impl<SP: Deref> Channel<SP> where
	pub fn queue_fail_malformed_htlc<L: Deref>(
 &mut self, htlc_id_arg: u64, failure_code: u16, sha256_of_onion: [u8; 32], logger: &L
	) -> Result<(), ChannelError> where L::Target: Logger {
 self.fail_htlc(htlc_id_arg, (failure_code, sha256_of_onion), true, logger)
 self.fail_htlc(htlc_id_arg, (sha256_of_onion, failure_code), true, logger)
 .map(|msg_opt| assert!(msg_opt.is_none(), "We forced holding cell?"))
	}

Expand All@@ -2901,7 +2899,7 @@ impl<SP: Deref> Channel<SP> where
	/// return `Ok(_)` if preconditions are met. In any case, `Err`s will only be
	/// [`ChannelError::Ignore`].
	fn fail_htlc<L: Deref, E: FailHTLCContents + Clone>(
 &mut self, htlc_id_arg: u64, err_packet: E, mut force_holding_cell: bool,
 &mut self, htlc_id_arg: u64, err_contents: E, mut force_holding_cell: bool,
 logger: &L
	) -> Result<Option<E::Message>, ChannelError> where L::Target: Logger {
 if !matches!(self.context.channel_state, ChannelState::ChannelReady(_)) {
Expand DownExpand Up@@ -2968,18 +2966,18 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 log_trace!(logger, "Placing failure for HTLC ID {} in holding cell in channel {}.", htlc_id_arg, &self.context.channel_id());
 self.context.holding_cell_htlc_updates.push(err_packet.to_htlc_update_awaiting_ack(htlc_id_arg));
 self.context.holding_cell_htlc_updates.push(err_contents.to_htlc_update_awaiting_ack(htlc_id_arg));
 return Ok(None);
 }

 log_trace!(logger, "Failing HTLC ID {} back with {} message in channel {}.", htlc_id_arg,
 E::Message::name(), &self.context.channel_id());
 {
 let htlc = &mut self.context.pending_inbound_htlcs[pending_idx];
 htlc.state = err_packet.clone().to_inbound_htlc_state();
 htlc.state = err_contents.clone().to_inbound_htlc_state();
 }

 Ok(Some(err_packet.to_message(htlc_id_arg, self.context.channel_id())))
 Ok(Some(err_contents.to_message(htlc_id_arg, self.context.channel_id())))
	}

	// Message handlers:
Expand DownExpand Up@@ -3576,7 +3574,7 @@ impl<SP: Deref> Channel<SP> where
 // the limit. In case it's less rare than I anticipate, we may want to revisit
 // handling this case better and maybe fulfilling some of the HTLCs while attempting
 // to rebalance channels.
 match &htlc_update {
let fail_htlc_res = match &htlc_update {
 &HTLCUpdateAwaitingACK::AddHTLC {
 amount_msat, cltv_expiry, ref payment_hash, ref source, ref onion_routing_packet,
 skimmed_fee_msat, blinding_point, ..
Expand DownExpand Up@@ -3604,6 +3602,7 @@ impl<SP: Deref> Channel<SP> where
 }
 }
 }
 None
 },
 &HTLCUpdateAwaitingACK::ClaimHTLC { ref payment_preimage, htlc_id, .. } => {
 // If an HTLC claim was previously added to the holding cell (via
Expand All@@ -3617,40 +3616,33 @@ impl<SP: Deref> Channel<SP> where
 { monitor_update } else { unreachable!() };
 update_fulfill_count += 1;
 monitor_update.updates.append(&mut additional_monitor_update.updates);
 None
 },
 &HTLCUpdateAwaitingACK::FailHTLC { htlc_id, ref err_packet } => {
 match self.fail_htlc(htlc_id, err_packet.clone(), false, logger) {
 Ok(update_fail_msg_option) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(update_fail_msg_option.is_some());
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 Some(self.fail_htlc(htlc_id, err_packet.clone(), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 },
 &HTLCUpdateAwaitingACK::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 match self.fail_htlc(htlc_id, (failure_code, sha256_of_onion), false, logger) {
 Ok(update_fail_malformed_opt) => {
 debug_assert!(update_fail_malformed_opt.is_some()); // See above comment
 update_fail_count += 1;
 },
 Err(e) => {
 if let ChannelError::Ignore(_) = e {}
 else {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 }
 }
 }
 },
 Some(self.fail_htlc(htlc_id, (sha256_of_onion, failure_code), false, logger)
 .map(|fail_msg_opt| fail_msg_opt.map(|_| ())))
 }
 };
 if let Some(res) = fail_htlc_res {
 match res {
 Ok(fail_msg_opt) => {
 // If an HTLC failure was previously added to the holding cell (via
 // `queue_fail_{malformed_}htlc`) then generating the fail message itself must
 // not fail - we should never end up in a state where we double-fail
 // an HTLC or fail-then-claim an HTLC as it indicates we didn't wait
 // for a full revocation before failing.
 debug_assert!(fail_msg_opt.is_some());
 update_fail_count += 1;
 },
 Err(ChannelError::Ignore(_)) => {},
 Err(_) => {
 panic!("Got a non-IgnoreError action trying to fail holding cell HTLC");
 },
 }
 }
 }
 if update_add_count == 0 && update_fulfill_count == 0 && update_fail_count == 0 && self.context.holding_cell_update_fee.is_none() {
Expand Down

47 changes: 21 additions & 26 deletions
lightning/src/ln/channelmanager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4344,7 +4344,7 @@ where
 if let Some(ChannelPhase::Funded(ref mut chan)) = peer_state.channel_by_id.get_mut(&forward_chan_id) {
 let logger = WithChannelContext::from(&self.logger, &chan.context);
 for forward_info in pending_forwards.drain(..) {
 match forward_info {
let queue_fail_htlc_res = match forward_info {
 HTLCForwardInfo::AddHTLC(PendingAddHTLCInfo {
 prev_short_channel_id, prev_htlc_id, prev_funding_outpoint, prev_user_channel_id,
 forward_info: PendingHTLCInfo {
Expand DownExpand Up@@ -4390,40 +4390,35 @@ where
 ));
 continue;
 }
 None
 },
 HTLCForwardInfo::AddHTLC { .. } => {
 panic!("short_channel_id != 0 should imply any pending_forward entries are of type Forward");
 },
 HTLCForwardInfo::FailHTLC { htlc_id, err_packet } => {
 log_trace!(logger, "Failing HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_htlc(
 htlc_id, err_packet, &&logger
 ) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 Some((chan.queue_fail_htlc(htlc_id, err_packet, &&logger), htlc_id))
 },
 HTLCForwardInfo::FailMalformedHTLC { htlc_id, failure_code, sha256_of_onion } => {
 log_trace!(self.logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 if let Err(e) = chan.queue_fail_malformed_htlc(htlc_id, failure_code, sha256_of_onion, &self.logger) {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(self.logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_malformed_htlc() were not met");
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 log_trace!(logger, "Failing malformed HTLC back to channel with short id {} (backward HTLC ID {}) after delay", short_chan_id, htlc_id);
 let res = chan.queue_fail_malformed_htlc(
 htlc_id, failure_code, sha256_of_onion, &&logger
 );
 Some((res, htlc_id))
@vladimirfomenevladimirfomeneJan 10, 2024

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for storing the result of the function call in a variable res instead of putting the function call in the tuple as done on L4400?
@valentinewallacevalentinewallaceJan 10, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I thought it was more readable this way since it wouldn't all fit in one line like with L4400
 },
 };
 if let Some((queue_fail_htlc_res, htlc_id)) = queue_fail_htlc_res {
 if let Err(e) = queue_fail_htlc_res {
 if let ChannelError::Ignore(msg) = e {
 log_trace!(logger, "Failed to fail HTLC with ID {} backwards to short_id {}: {}", htlc_id, short_chan_id, msg);
 } else {
 panic!("Stated return value requirements in queue_fail_{{malformed_}}htlc() were not met");
@shaavanshaavanDec 19, 2023

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are achieving a DRY code here, and that's great!
But we are also combining the panic messages that can be generated from two different sources here.

Would this be an optimal thing to do?
@TheBlueMattTheBlueMattJan 9, 2024

Copy link


Copy Markdown

Collaborator
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point (interpreting this as "our stack trace from the panic message won't be quite as useful as we won't be able to differentiate between the two cases"), however in this case I'm not sure we care too much about being able to differentiate, so the DRYing is likely worth more. Further, we should generally be able to differentiate the cases anyway, as logs should show different messages being received.
 }
 // fail-backs are best-effort, we probably already have one
 // pending, and if not that's OK, if not, the channel is on
 // the chain and sending the HTLC-Timeout is their problem.
 continue;
 }
 }
 }
 } else {
Expand Down