Published on: 2019-02-08T11:13:05+00:00
The conversation revolves around the commitment of more data and the issue of signaling in the onion packet version. When it comes to CLTV (Check Lock Time Verify), the outgoing CLTV value in the onion payload is committed for both intermediate hops and final hops. Nodes will reject any forward that has a CLTV value for the next leg that is not far enough in the future based on the incoming CLTV value. To ensure proper functioning, a node needs to keep a cache of shared secrets used until the outgoing_cltv_value from the onion dips below incoming_cltv_value - cltv_expiry_delta.To address the problem of injecting a new HTLC with a fresher CLTV, the proposed solution involves extending the associated data payload to cover the CLTV as well. However, this may need to be rolled out differently from the suggested method. The use of new packet versions in the Sphinx packet may not work if the route contains nodes that do not understand the new version of the packet. In such cases, nodes prior to non-upgraded nodes would have to downgrade the packet version from v1 to v0, which is understood by the non-upgraded node. This could be done via an instruction in the per-hop payload itself.Committing to the packet version is deemed unnecessary since if a node wants to cause rejection, it can tamper with anything in the payload, leading to an HMAC failure. In the long term, payment details might end up being included in the Sphinx packet. It is suggested that the serialized HTLC output could be used as it represents the on-chain representation of the payment and includes all relevant details.A potential de-anonymization vector known as a "replay" attack is also highlighted in the message. This attack is possible if an adversary injects a stale packet into the network to observe its propagation. To prevent this, implementations should maintain a Sphinx reply cache of past shared secrets and reject packets with identical shared secrets already in the cache. The absolute CLTV can serve as the lifetime of a payment circuit session, ensuring that old shared secrets state is garbage collected.The sphinx packet construction allows optional plaintext data to be authenticated alongside the packet. Currently, the payment hash is bound to the packet. If the pre-image has already been revealed, the victim can instantly pull the payment, adding a cost to a replay attempt. However, since the CLTV isn't authenticated, it's possible to inject a new HTLC with a fresher CLTV. To tackle this, the associated data payload can be extended to cover the CLTV and bind the adversary to using the same CLTV details. This would cause the victim node to reject the HTLC since it has already expired. Additionally, more payment details, such as the HTLC amount, can be added to make the probing vector more expensive for the adversary.To implement these changes, a new packet version in the Sphinx packet can be used, and it can be signaled with a global feature bit. Nodes encountering this new version would include the extra information in the AD for their MAC check. Furthermore, committing to the packet version can prevent nodes from swapping it out with another version, potentially causing rejection by another node.In the long term, all payment details may end up being included in the Sphinx packet, while link level details such as the HTLC ID would remain outside in the update_add_htlc message.
Updated on: 2023-07-31T21:26:53.494193+00:00