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

CLN: Research Project on CLN Pay Plugin #7219

Open
vincenzopalazzo opened this issue Apr 14, 2024 · 2 comments
Open

CLN: Research Project on CLN Pay Plugin #7219

vincenzopalazzo opened this issue Apr 14, 2024 · 2 comments
Assignees

Comments

@vincenzopalazzo
Copy link
Collaborator

vincenzopalazzo commented Apr 14, 2024

Posting here just for accountability due that it is my own project and not affiliate with Blockstream


Description

The pay command is central to the Core Lightning implementation, and routing is fundamental to the Lightning Network.

Currently, many users are encountering issues with the Core Lightning pay command, for example:

  • Issue #7180
  • Issue #6793
  • Many CLN users are resorting to rewriting the plugin found at BoltzExchange to address their specific needs
  • I have encountered numerous other examples through discussions with community members, ex. Breeze.

This project proposes to revisit the fundamentals and aims to achieve the following steps:

  • Propose a new experimental plugin (ideally beyond research quality, but research quality is acceptable if it leads to improvements).
  • Employ the Strategy Pattern to implement the most effective routing algorithm for specific cases (starting with simple scenarios):
    • Direct payments to nodes connected by a channel (a required goal, essentially a loop).
    • Apply standard graph algorithms (required, even if they don't lead to immediate breakthroughs).
  • Retry different strategies from the previous step but record information from each attempt:
    • This approach helps avoid repeatedly trying the same path (avoiding a "monkey approach").
    • Analyze why payments are failing.
  • Enhance the diagnostics of payments, e.g., identifying which route is failing or the path where the payment succeeded:
    • Currently, the only method available is examining logs, which does not guarantee certainty in our integration testing that the pay command is performing as expected.

Difficulty: Hard
Requirements: Design Patterns, Coding Skills, Fearlessness in the face of failure
Pre-Requisites: Have been involved in some of the related projects in core lightning or plugins in general.
Mentor: @vincenzopalazzo (find all the contacts in the github profile, use them to ask not the issue thread)


Leave a 👍🏼 or OFC 👎🏼 if it is a bad idea

@cdecker
Copy link
Member

cdecker commented Apr 18, 2024

Sorry, I'm not following what you are proposing on a very concrete level. These all sound like things that are either already in pay (direct_pay_override_paymod for example), or sound like an outer loop around multiple pay implementations.

As it stands I'm not seeing the need to start a separate pay plugin, rather we should be applying all these things, or fix the existing implementation in the pay plugin.

@vincenzopalazzo
Copy link
Collaborator Author

Mh not sure if I get the problem here @cdecker

The goal of the project is to get some interested people in this graph research, that is not required to deal with a complex codebase like the pay command.

These all sound like things that are either already in pay (direct_pay_override_paymod for example)

Mh in fact the approach is a "Back to the basic" approach, and also idk if you can set direct_pay_override_paymod from the command line like cln pay <bolt> --force-algo direct or something like that. But it required to hack the code, or at least is what I understand, so please feel free to correct me.

In addition, I do not think there is any way to get information about the route that core lightning is using, except look at the log, but looking at the log making extremely difficult testing.

I'm not seeing the need to start a separate pay plugin, rather we should be applying all these things, or fix the existing implementation in the pay plugin.

I do not think that fixing or extending a very complex part of our code like pay is a nice summer of bitcoin project that can get any real attraction. This sounds more like a full-time job that needs to be done by someone with experience. For sure the person who will take this project can fix our problem with pay command, but this is a follow-up step. Maybe, I am wrong and someone fix/improves the pay plugin and prove that it was a peace of cake

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

No branches or pull requests

2 participants