SURBs as a Solution for Protocol-Level Payment ACKs

Summary:

The Lightning Network is a protocol for making fast and cheap transactions over the Bitcoin network. Recently, the network has been doing more design work related to the Sphinx packet, which prompted a re-visit of the original Sphinx paper to refresh memory on the finer details of the protocol. The paper highlighted the potential use of single-use-reply-blocks (SURBs) to implement a "payment ACK" for each sent HTLC. Right now, HTLC routing is mainly a game of "send and hope it arrives," as there is no clear indication of when an HTLC has arrived at its destination. Instead, you only receive a protocol level message if the HTLC failed or was successfully redeemed. As part of BOLT 1.1, it was agreed upon that implementing some sort of "payment ACK" feature would be beneficial. A payment ACK scheme is strongly desired because it allows the sender to know when a payment has reached the receiver, which is useful for many higher-level protocols. Currently, the sender is unable to distinguish an HTLC being "black holed" from one that's actually reached the sender, and they're just holding onto it. Implementing a payment ACK feature would also aid in AMP implementations by allowing feedback on successfully routed splits. If the receiver ACKs each partial payment, then implementations can more aggressively split payments as they're able to gain assurance that the first portion of the payment has actually reached the sender and wasn't black holed. Enforcing and relying on ACKs may also thwart any games receivers might play, claiming that the HTLC "didn't actually arrive." To implement payment ACKs, the sender can craft a SURB (for the ACK), and mark the receipt of the SURB as the payment ACK itself. Creating and processing a SURB is identical to the regular HTLC packets used today, and the code impact to the code sphinx packet logic is minimal. Then, the e2e payload is reintroduced so that it can carry the SURB in the forward direction (HLTC add). The backwards packet would also have a payload of random bytes with the same size as a regular packet to make them look identical on the wire. This approach is better than a potential client-server payment negotiation protocol as it doesn't require any additional servers alongside the node, maintains sender anonymity, and doesn't rely on any sort of PKI. From the perspective of packet analysis, errors today are identifiable due to the packet size, but SURBs have the same profile as regular HTLC adds since they use the same Sphinx packet format. Unlike the wrapped onion errors, intermediate nodes are also able to validate the integrity of the payment ACK as they'll check the per-hop MAC as normal. Additionally, the replies naturally create cover traffic as they look like regular payments.One downside is that this would essentially double the size of HTLC messages on the network today, as they need to carry SURB. Most candidates for possible rendezvous schemes to deploy would also increase the packet size if allowed up to 20 hops in both directions. By re-introducing SURBs, there is an opportunity to cleanly solve the payment ACK issue, re-use a component of Lightning, enable protocol-level streaming/subscription payments, and make replies indistinguishable-ish from regular payments.

Updated on: 2023-05-23T01:54:58.219601+00:00