Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add `createonion` and `sendonion` RPC commands #3260
This PR introduces two new RPC methods:
Depending on whether
cdecker left a comment
That's a really weird naming convention if you ask me, but I changed it for the sake of consistency. I'll keep
Thanks @niftynei and @rustyrussell for the extensive feedback. I tried to address everything, and the resulting fixup stack is a bit big. Here's the range-diff for an easier comparison: eefd97ff9671b99714305e296e951d4c3075539c..124773bfb14c56e0ea6d474a5872bf3b7581cd72
These are useful for the `createonion` JSON-RPC we're going to build next. The secret is used for the optional `session_key` while the hex-encoded binary is used for the `assocdata` field to which the onion commits. The latter does not have a constant size, hence the raw binary conversion.
This is what provides us with the ability to add custom fields in the payload when using `createonion` so make sure we actually have access to it. Changelog-Changed: The TLV payloads for the onion packets are no longer considered an experimental feature and generally available. Changelog-Added: Plugins may now handle modern TLV-style payloads via the `htlc_accepted` hook Signed-off-by: Christian Decker <@cdecker>
This allows us to create an onion in the JSON-RPC that we can then later inject with the `sendonion` command that we're about to implement.
If we use `sendonion` we don't actually know the destination, so we make the destination a pointer which is NULL if we don't know.
We are breaking with a couple of assumptions, namely that we have the `path_secrets` to decode the error onion. If this happens we just want it to error out.
When using `sendonion` with `shared_secrets` we may be able to decode the onioned error message but we cannot infer which node reported the failure since we don't know which nodes where involved.
Same rationale as the previous commit: we may not have the channels in the path so we don't try to infer the failing channel from the error.
This means that c-lightning can now internally decrypt an eventual error message, and not force the caller to implement the decryption. The main difficulty was that we now have a new state (channels and nodes not specified, while shared_secrets are specified) which needed to be handled.
If we can't decode the onion, because the onion got corrupted or we used `sendonion` without specifying the `shared_secrets` used, the best we can do is tell the caller instead.
Changelog-Added: Added `createonion` and `sendonion` JSON-RPC methods allowing the implementation of custom protocol extensions that are not directly implemented in c-lightning itself.
We're about to create a param helper for sphinx hops and this struct seems like the correct place to store the result.
If we initiated the payment using an externally generated onion we don't know what the final hop gets, or even who it is, so we don't display the amount in these cases. I chose to show `null` instead in order not to break dependees that rely on the value being there.