You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: