-
Notifications
You must be signed in to change notification settings - Fork 339
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.
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
Support intercepting onion messages for offline peers #2973
Changes from 1 commit
e8f7fe1
1c28cc0
7213458
1fc8f11
4c7ecaa
be31e63
6613f1f
edc86e3
a5ada64
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -175,6 +175,8 @@ where | |
message_router: MR, | ||
offers_handler: OMH, | ||
custom_handler: CMH, | ||
intercept_messages_for_offline_peers: bool, | ||
pending_events: Mutex<Vec<Event>>, | ||
} | ||
|
||
/// [`OnionMessage`]s buffered to be sent. | ||
|
@@ -796,6 +798,28 @@ where | |
pub fn new( | ||
entropy_source: ES, node_signer: NS, logger: L, node_id_lookup: NL, message_router: MR, | ||
offers_handler: OMH, custom_handler: CMH | ||
) -> Self { | ||
Self::new_inner( | ||
entropy_source, node_signer, logger, node_id_lookup, message_router, | ||
offers_handler, custom_handler, false | ||
) | ||
} | ||
|
||
/// | ||
pub fn new_with_offline_peer_interception( | ||
entropy_source: ES, node_signer: NS, logger: L, node_id_lookup: NL, | ||
message_router: MR, offers_handler: OMH, custom_handler: CMH | ||
) -> Self { | ||
Self::new_inner( | ||
entropy_source, node_signer, logger, node_id_lookup, message_router, | ||
offers_handler, custom_handler, true | ||
) | ||
} | ||
|
||
fn new_inner( | ||
entropy_source: ES, node_signer: NS, logger: L, node_id_lookup: NL, | ||
message_router: MR, offers_handler: OMH, custom_handler: CMH, | ||
intercept_messages_for_offline_peers: bool | ||
) -> Self { | ||
let mut secp_ctx = Secp256k1::new(); | ||
secp_ctx.seeded_randomize(&entropy_source.get_secure_random_bytes()); | ||
|
@@ -809,6 +833,8 @@ where | |
message_router, | ||
offers_handler, | ||
custom_handler, | ||
intercept_messages_for_offline_peers, | ||
pending_events: Mutex::new(Vec::new()), | ||
} | ||
} | ||
|
||
|
@@ -1004,6 +1030,11 @@ where | |
} | ||
} | ||
} | ||
let mut events = Vec::new(); | ||
core::mem::swap(&mut *self.pending_events.lock().unwrap(), &mut events); | ||
for ev in events { | ||
handler.handle_event(ev); | ||
} | ||
} | ||
} | ||
|
||
|
@@ -1081,6 +1112,13 @@ where | |
e.get_mut().enqueue_message(onion_message); | ||
log_trace!(logger, "Forwarding an onion message to peer {}", next_node_id); | ||
}, | ||
_ if self.intercept_messages_for_offline_peers => { | ||
self.pending_events.lock().unwrap().push( | ||
Event::OnionMessageIntercepted { | ||
peer_node_id: next_node_id, message: onion_message | ||
} | ||
); | ||
}, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I omitted it because of our past discussions of avoiding adding logs that would allow someone to adversarially blow up our logs on disk (there are some pre-existing ones in this method, ofc). So I'm not sure it's a good idea? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm... I thought that was only applicable for higher-level logging like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, happy to add it in follow-up too, no reason to hold the PR up. |
||
_ => { | ||
log_trace!( | ||
logger, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use a separate queue if these aren't persisted? If we instead use
message_recipients
for buffering -- with a new variant -- then we can re-useoutbound_buffer_full
and generate events in the same manner asConnectionNeeded
. Otherwise, we are left with two different systems for buffering messages and generating events.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I believe with this approach an attacker may be able to fragment our heap by continually sending bogus forwards to a new fake peer each time (where each fake forward results in a
VecDeque
allocation). I think my other reasoning is that because the events generated may all be bogus, they shouldn't be allowed to count towardsoutbound_buffer_full
, since currently all of that traffic is known to be more legitimate (either an outbound OM initiated by the LDK user or a forward to a peer that is connected).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, though this seems to be an issue already with onion messages, FWIW. Processing an
OnionMessage
involves allocating aVec<u8>
forPacket::hop_data
.Right, though this makes me wonder if the user should specify which peers it supports forwarding to. See other comment about the race condition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline. Yeah, I suppose specifying which peers support forwarding adds a bit of user to the burden. They are already doing this when processing events, so no sense forcing them to duplicate it here an risk inconsistencies.