mirror of
https://github.com/ACINQ/eclair.git
synced 2025-02-22 22:25:26 +01:00
2ad22602fd
* Return unwrapped decryption failure onion When we fail to decrypt an onion failure packet, we should return the result of the unwrapping process. When using trampoline, this will let us properly re-encrypt the failure and relay it upstream to the previous trampoline node, until it reaches the sender. * Refactor HTLC failure creation We refactor the shared secret extraction to a dedicated function. * Refactor HTLC failure reason We previously used an `Either[ByteVector, FailureMessage]` to encode: - a downstream error that we couldn't decrypt and must re-wrap (left) - a local error that we must encrypt (right) This won't be sufficient for trampoline, because we will need to handle the following cases: - a downstream error that we couldn't decrypt and must re-wrap - a local error for the node who created the *outer* onion (which we encrypt with the sphinx shared secret of the outer onion) - a local error for the node who created the *trampoline* onion (which we encrypt with the sphinx shared secret of the trampoline onion and then with the shared secret of the outer onion) We thus introduce a trait, which currently only contains the first two cases. We will extend this trait when adding support for trampoline failures. This is a pure refactoring without any behavior changes so far, which will simplify the future trampoline changes. * Include trampoline onion in final trampoline payloads When we receive a (non-blinded) payment that uses trampoline, we keep the trampoline onion to be able to distinguish this payment from a non-trampoline payment.
540 B
540 B
Guides
This section contains how-to guides for more advanced scenarios: