<div dir="ltr"><div>Hi y&#39;all,</div><div><br></div><div>Recently we&#39;ve started to do more design work related to the Sphinx packet</div><div>(EOB format, rendezvous protocol). This prompted me to re-visit the original</div><div>Sphinx paper to refresh my memory w.r.t some of the finer details of the</div><div>protocol.  While I was re-reading the paper, I realized that we may be able</div><div>to use use SURBs (single-use-reply-blocks) to implement a &quot;payment ACK&quot; for</div><div>each sent HTLC.</div><div><br></div><div>(it&#39;s worth mentioning that switching to HORNET down the line would solve</div><div>this problem as well since the receiver already gets a multi-use backwards</div><div>route that they can use to send information back to the receiver)</div><div><br></div><div>Right now HTLC routing is mainly a game of &quot;send and hope it arrives&quot;, as</div><div>you have no clear indication of the _arrival_ of an HTLC at the destination.</div><div>Instead, you only receive a protocol level message if the HTLC failed for</div><div>w/e reason, or if it was successfully redeemed.  As part of BOLT 1.1, it was</div><div>agreed upon that we should implement some sort of &quot;payment ACK&quot; feature. A</div><div>payment ACK scheme is strongly desired as it:</div><div><br></div><div>  * Allows the sender to actually know when a payment has reached the</div><div>    receiver which is useful for many higher level protocols. Atm, the</div><div>    sender is unable to distinguish an HTLC being &quot;black holed&quot; from one</div><div>    that&#39;s actually reached the sender, and they&#39;re just holding on to it.</div><div>  * AMP implementations would be aided by being able to receive feedback on</div><div>    successfully routed splits. If we&#39;re able to have the receiver ACK each</div><div>    partial payment, then implementations can more aggressively split</div><div>    payments as they&#39;re able to gain assurance that the first 2 BTC of 5</div><div>    total have actually reached the sender, and weren&#39;t black holed.</div><div>  * Enforcing and relying on ACKs may also thwart silly games receivers</div><div>    might play, claiming that the HTLC &quot;didn&#39;t actually arrive&quot;.</div><div><br></div><div>Some also call this feature a &quot;soft error&quot; as a possible implementation</div><div>might to re-use the existing onion error protocol we&#39;ve deployed today.  For</div><div>reference, in order to send back errors back long the route in a way that</div><div>doesn&#39;t reveal the sender of the HTLC to the receiver (or any of the</div><div>intermediate nodes) we re-use the shared secret each hop has derived, and</div><div>onion wrap a MAC&#39;d error to the sender. Each hop can&#39;t actually check that</div><div>they&#39;ve received a well formed error, but the sender is able to attribute an</div><div>error to a node in the route based on which shared secret they&#39;re able to</div><div>check the MAC with.</div><div><br></div><div>The original Sphinx packet format has a way for the receiver to send a</div><div>message back to the sender. This was originally envisioned to allow the</div><div>receiver to send a replay email/message back to the sender without knowing</div><div>who they were, and also in a manner that was bit-wise indistinguishable from</div><div>a regular forwarded packet. This is called a SURB or &quot;single use reply</div><div>block&quot;. A SURB is composed of: a pre-crafted sphinx packet for the</div><div>&quot;backwards route&quot; (which can be distinct from the forwards route), the first</div><div>hop of the backwards route, and finally a symmetric key to use when</div><div>encrypting the reply.</div><div><br></div><div>When we more or less settled on using Sphinx, we started to remove things</div><div>that we didn&#39;t have a clear use for at the time. Two things that were</div><div>removed were the original end-to-end payload, and also the SURB. Removing</div><div>the payload made the packet size smaller, and it didn&#39;t seem realistic to</div><div>give _each_ hop a SURB to send reply back.</div><div><br></div><div>In order to implement payment ACKs, we can have the sender craft a SURB (for</div><div>the ACK), and mark the receipt of the SURB as the payment ACK itself.</div><div>Creating and processing a SURB is identical to the regular HTLC packets we</div><div>use today. As a result, the code impact to the code sphinx packet logic is</div><div>minimal. We&#39;d then also re-introduce the e2e payload so we can carry the</div><div>SURB in the forward direction (HLTC add). The backwards packet would also</div><div>have a payload of random bytes with the same size as a regular packet to</div><div>make them look identical on the wire.</div><div><br></div><div>This payload can further be put to use in order to implement streaming or</div><div>subscription payments in a way. Since we must add a payload for in order to</div><div>send/reply look the same, we can also piggy back some useful additional</div><div>data. Each time a payment is sent, the receiver can use the extra payload to</div><div>stack on details such as:</div><div>  * A new invoice to pay for the metered service being paid for.</div><div>  * An invoice along with a deadline for when this must be paid, lest the</div><div>    subscription service expire.</div><div>  * Details of lightning-native API</div><div>  * etc, etc</div><div><br></div><div>IMO, this approach is better than a potential client-server payment</div><div>negotiation protocol as it doesn&#39;t require any additional servers along side</div><div>the node, also maintains sender anonymity, and doesn&#39;t rely on any sort of</div><div>PKI.</div><div><br></div><div>From the prospective of packet-analysis, errors today are identifiable due</div><div>to the packet size (though we do pad them out to avoid being able to</div><div>distinguish some errors from others on the wide). SURBs on the other hand,</div><div>have the same profile as regular HTLC adds since they use the same Sphinx</div><div>packet format.  Unlike the wrapped onion errors, intermediate nodes are also</div><div>able to validate the integrity of the payment ACK as they&#39;ll check the per-hop</div><div>MAC as normal. Additionally, the replies naturally create cover traffic as</div><div>they look like regular payments.</div><div><br></div><div>One down side is that this would essentially double the size of HTLC</div><div>messages on the network today, as they need to also carry SURB.  Most</div><div>candidates for possible rendezvous schemes to deploy would also increase the</div><div>packet size if up to 20 hops it be allowed in both directions.  We also</div><div>(from my PoV), don&#39;t really have a feel on how much of an issue the 1.2KB</div><div>HTLC packet size is today in the network.</div><div><br></div><div>By re-introducing SURBs, we have an opportunity to cleanly solve the payment</div><div>ACK issue, re-use a component of our favorite thing in Lightning, enable</div><div>protocol-level streaming/subscription payments and also make replies</div><div>indistinguishable-ish from regular payments.</div><div><br></div><div>Thoughts?</div><div><br></div><div>-- Laolu</div><div><br></div></div>