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

Blinded route should hold alias instead of actual scid? #6588

Closed
orbitalturtle opened this issue Aug 19, 2023 · 1 comment
Closed

Blinded route should hold alias instead of actual scid? #6588

orbitalturtle opened this issue Aug 19, 2023 · 1 comment
Labels
in diagnostic issue under diagnostic

Comments

@orbitalturtle
Copy link
Contributor

Issue and Steps to Reproduce

Ahoy there, I'm helping @carlaKC with interop of her lovely route blinding PR (lightningnetwork/lnd#7267) with CLN.

If I'm understanding right, one issue seems to be that when CLN creates a blinded route (returned by fetchinvoice), the encrypted data for the final hop (reached by a private channel) should include a scid alias as the short_channel_id field. But instead it adds the actual scid.

Walking through this, I use the setup described at the bottom of @carlaKC's PR. So we have nodes A (LND) - B (CLN) - C (CLN) - D (CLN), where C and D are connected by a private channel. Then I follow the rest of Carla's instructions to send a blinded payment from A to D.

The HTLC gets stuck at C because C cannot find a route to D, according to logs in C. This seems to happen here:

if (!privacy_leak_ok

Using a debugger here, the problem seems to be that the short_channel_id provided to this function (which originally comes from the encrypted data of the final hop) is the short_channel_id, instead of the alias, which the comment on 681 explains is required here.

When I comment out #686-688, and recompile, it successfully finds the channel, and forwards the HTLC to D! Not a good solution of course, but helps to verify that this is the problem area...

@orbitalturtle
Copy link
Contributor Author

Closing as it seems like this has been fixed :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in diagnostic issue under diagnostic
Projects
None yet
Development

No branches or pull requests

4 participants