Skip to content
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

Wake up wallet nodes before relaying messages or payments #2865

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Jun 11, 2024

This PR ports some of the architecture related to wallet wake-up from feature branches to master. It should be reviewed commit-by-commit, while comparing to feature branches to get a feel for the changes that will be needed on the feature branches to adapt to this architecture.

Note how the PeerReadyNotifier can easily be extended to send push notifications to wallet nodes before waiting for an incoming connection from them.

@t-bast t-bast force-pushed the wake-up-before-relay branch 2 times, most recently from 89d3a1d to b5a8d98 Compare June 18, 2024 14:25
def start(): Behavior[Command] = {
r.payload.outgoing match {
case Left(walletNodeId) => wakeUp(walletNodeId)
case Right(requestedShortChannelId) =>
Copy link
Member Author

Choose a reason for hiding this comment

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

Note how this can be extended to detect "custom" scids and insert the wake-up step, by resolving the walletNodeId using our push notifications DB (or an existing channel if we have one, which avoids a DB call).

thomash-acinq
thomash-acinq previously approved these changes Jun 19, 2024
@t-bast
Copy link
Member Author

t-bast commented Jun 19, 2024

I amended the last commit which contained a bug in nextWalletNodeId: the case where we potentially relay to a non-blinded wallet node is when the recipient is a ClearRecipient with a non-empty trampoline packet, not a TrampolineRecipient. It's also important in that case that we only attempt wake-up when we're sure the next node is a wallet node, so this currently returns None and must be enriched in feature branches with a call to the push notifications DB to check whether the next node is a wallet.

Comment on lines +143 to +144
// When relaying to a trampoline node, the next node may be a wallet node directly connected to us, but we don't
// want to have false positives. Feature branches should check an internal DB/cache to confirm.
case r: ClearRecipient if r.nextTrampolineOnion_opt.nonEmpty => None
Copy link
Member Author

Choose a reason for hiding this comment

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

This case can be extended to wake-up current Phoenix wallets: we should check our push notifications DB here and if it has an entry for the next node, we should return it, otherwise we should return None (this is a trampoline relay to a non-wallet node).

thomash-acinq
thomash-acinq previously approved these changes Jun 20, 2024
This commit doesn't contain any logical change, we just move code to
align with the FSM flow. It makes it easier to follow the progress of
the state machine to always scroll down when advancing states.
We refactor `NodeRelay.scala` to re-order some steps, without making
meaningful functional changes. The steps are:

1. Fully receive the incoming payment
2. Resolve the next node (unwrap blinded paths if needed)
3. Wake-up the next node if necessary (mobile wallet)
4. Relay outgoing payment

Note that we introduce a wake-up step, that will be enriched in future
commits and can be extended to include mobile notifications. The file
is now also easier to follow, as steps are done linearly by simply
scrolling down.
We allow relaying data to contain a wallet `node_id` instead of an scid.
When that's the case, we start by waking up that wallet node before we
try relaying onion messages or payments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants