SURBs as a Solution for Protocol-Level Payment ACKs [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2019-02-19T00:50:25+00:00


Summary:

Bitcoin Lightning Network developer Rusty Russell has proposed using single-use-reply-blocks (SURBs) to implement a "payment ACK" for each sent Hashed Time-Locked Contract (HTLC). Currently, there is no clear indication of when an HTLC arrives at its destination, making HTLC routing a game of "send and hope it arrives". The payment ACK feature would allow the sender to know when a payment has reached the receiver, aiding in Assured Message Payment (AMP) implementation and enabling the development of higher-level protocols. It would also help in enforcing and relying on acknowledgments, which can prevent receivers from claiming that the HTLC "didn't actually arrive". SURBs are composed of a pre-crafted Sphinx packet for the backwards route, the first hop of the backwards route, and a symmetric key for encrypting the reply.Olaoluwa Osuntokun, another Lightning Network developer, supports the implementation of SURBs as a way to provide an acknowledgment for each sent HTLC. The current protocol only provides a message if an HTLC fails or is redeemed. Implementing payment ACKs using SURBs would allow the sender to distinguish between an HTLC being "black holed" and one that has reached the receiver. This would be beneficial for AMP implementations by providing feedback on successfully routed splits. Enforcing and relying on ACKs can also prevent receivers from playing games and falsely claiming that the HTLC didn't arrive. The use of SURBs in the forward direction allows for the carrying of ACKs, while the payload of random bytes in the backwards packet makes them indistinguishable from regular packets.By implementing payment ACKs with SURBs, additional benefits can be achieved. The extra payload in the SURBs can be used to implement streaming or subscription payments, allowing the receiver to include details such as a new invoice or a deadline for payment. This approach is advantageous as it doesn't require additional servers, maintains sender anonymity, and doesn't rely on public key infrastructure. However, one downside is that it would double the size of HTLC messages on the network. Additionally, potential rendezvous schemes may also increase packet size if allowed up to 20 hops in both directions.The Lightning Network, a protocol for fast and cheap transactions over the Bitcoin network, has been focusing on the design work related to the Sphinx packet. The use of SURBs for payment ACKs was highlighted in the original Sphinx paper. Currently, HTLC routing lacks a clear indication of when an HTLC arrives at its destination, relying only on protocol level messages for failed or redeemed HTLCs. Implementing a payment ACK feature is desired to enable the sender to know when a payment has reached the receiver and to aid in AMP implementations. SURBs provide a solution by allowing the sender to craft a SURB as an ACK and mark its receipt as the payment ACK. The implementation of SURBs involves minimal code impact and reintroducing the end-to-end payload to carry the SURB in the forward direction. This approach solves the payment ACK issue, enables streaming/subscription payments, and makes replies indistinguishable from regular payments.


Updated on: 2023-07-31T21:26:29.767787+00:00