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

Revive "sendpay custom onion" feature #3227

Closed
bitonic-cjp opened this issue Oct 30, 2019 · 2 comments · Fixed by #3260
Closed

Revive "sendpay custom onion" feature #3227

bitonic-cjp opened this issue Oct 30, 2019 · 2 comments · Fixed by #3260

Comments

@bitonic-cjp
Copy link
Contributor

bitonic-cjp commented Oct 30, 2019

With the htlc_accepted feature in place, I tried to see if my plugin would work with C-Lightning. Conclusion: I'm still missing some functionality on the interface.

The main thing I'm missing is the ability to send customized data as onion payload - something along the lines of pull request #1715 . I believe that pull request was closed without being merged, and no equivalent functionality currently exists.

I'd like to revive it; hopefully I'll now have less trouble fighting merge conflicts with an ever-changing master branch. But before I do the hard work, I'd like to ask for consensus on this feature. This was the RPC interface design of pull request #1715 :

Each element of the "route" argument has optional "realm" and "data" elements. When given, "realm" overrides the default realm number (0) for that hop. When given, "data" overrides the default onion payload data for that hop.

This was designed before the Adelaide summit - it may need to be updated for the new realm number semantics.

Note that this design prefers to be feature-complete to such a degree that it allows the user to violate the Lightning protocol. The rationale is that it's good to be feature-complete, that it's really others' responsibility to make sure you're following the protocol, that sensible app developers will probably want to follow the protocol anyway, and that the ability to break the protocol is useful for testing our own code for robustness against others' protocol violations.

@cdecker
Copy link
Member

cdecker commented Nov 25, 2019

This should be addressed by #3260 i I'm not mistaken.

@bitonic-cjp
Copy link
Contributor Author

I believe so too.

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

Successfully merging a pull request may close this issue.

2 participants