{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-02-07\n📝 Original message:\nHi y'all,\n\nRecently we've started to do more design work related to the Sphinx packet\n(EOB format, rendezvous protocol). This prompted me to re-visit the original\nSphinx paper to refresh my memory w.r.t some of the finer details of the\nprotocol.  While I was re-reading the paper, I realized that we may be able\nto use use SURBs (single-use-reply-blocks) to implement a \"payment ACK\" for\neach sent HTLC.\n\n(it's worth mentioning that switching to HORNET down the line would solve\nthis problem as well since the receiver already gets a multi-use backwards\nroute that they can use to send information back to the receiver)\n\nRight now HTLC routing is mainly a game of \"send and hope it arrives\", as\nyou have no clear indication of the _arrival_ of an HTLC at the destination.\nInstead, you only receive a protocol level message if the HTLC failed for\nw/e reason, or if it was successfully redeemed.  As part of BOLT 1.1, it was\nagreed upon that we should implement some sort of \"payment ACK\" feature. A\npayment ACK scheme is strongly desired as it:\n\n  * Allows the sender to actually know when a payment has reached the\n    receiver which is useful for many higher level protocols. Atm, the\n    sender is unable to distinguish an HTLC being \"black holed\" from one\n    that's actually reached the sender, and they're just holding on to it.\n  * AMP implementations would be aided by being able to receive feedback on\n    successfully routed splits. If we're able to have the receiver ACK each\n    partial payment, then implementations can more aggressively split\n    payments as they're able to gain assurance that the first 2 BTC of 5\n    total have actually reached the sender, and weren't black holed.\n  * Enforcing and relying on ACKs may also thwart silly games receivers\n    might play, claiming that the HTLC \"didn't actually arrive\".\n\nSome also call this feature a \"soft error\" as a possible implementation\nmight to re-use the existing onion error protocol we've deployed today.  For\nreference, in order to send back errors back long the route in a way that\ndoesn't reveal the sender of the HTLC to the receiver (or any of the\nintermediate nodes) we re-use the shared secret each hop has derived, and\nonion wrap a MAC'd error to the sender. Each hop can't actually check that\nthey've received a well formed error, but the sender is able to attribute an\nerror to a node in the route based on which shared secret they're able to\ncheck the MAC with.\n\nThe original Sphinx packet format has a way for the receiver to send a\nmessage back to the sender. This was originally envisioned to allow the\nreceiver to send a replay email/message back to the sender without knowing\nwho they were, and also in a manner that was bit-wise indistinguishable from\na regular forwarded packet. This is called a SURB or \"single use reply\nblock\". A SURB is composed of: a pre-crafted sphinx packet for the\n\"backwards route\" (which can be distinct from the forwards route), the first\nhop of the backwards route, and finally a symmetric key to use when\nencrypting the reply.\n\nWhen we more or less settled on using Sphinx, we started to remove things\nthat we didn't have a clear use for at the time. Two things that were\nremoved were the original end-to-end payload, and also the SURB. Removing\nthe payload made the packet size smaller, and it didn't seem realistic to\ngive _each_ hop a SURB to send reply back.\n\nIn order to implement payment ACKs, we can have the sender craft a SURB (for\nthe ACK), and mark the receipt of the SURB as the payment ACK itself.\nCreating and processing a SURB is identical to the regular HTLC packets we\nuse today. As a result, the code impact to the code sphinx packet logic is\nminimal. We'd then also re-introduce the e2e payload so we can carry the\nSURB in the forward direction (HLTC add). The backwards packet would also\nhave a payload of random bytes with the same size as a regular packet to\nmake them look identical on the wire.\n\nThis payload can further be put to use in order to implement streaming or\nsubscription payments in a way. Since we must add a payload for in order to\nsend/reply look the same, we can also piggy back some useful additional\ndata. Each time a payment is sent, the receiver can use the extra payload to\nstack on details such as:\n  * A new invoice to pay for the metered service being paid for.\n  * An invoice along with a deadline for when this must be paid, lest the\n    subscription service expire.\n  * Details of lightning-native API\n  * etc, etc\n\nIMO, this approach is better than a potential client-server payment\nnegotiation protocol as it doesn't require any additional servers along side\nthe node, also maintains sender anonymity, and doesn't rely on any sort of\nPKI.\n\n\u003eFrom the prospective of packet-analysis, errors today are identifiable due\nto the packet size (though we do pad them out to avoid being able to\ndistinguish some errors from others on the wide). SURBs on the other hand,\nhave the same profile as regular HTLC adds since they use the same Sphinx\npacket format.  Unlike the wrapped onion errors, intermediate nodes are also\nable to validate the integrity of the payment ACK as they'll check the\nper-hop\nMAC as normal. Additionally, the replies naturally create cover traffic as\nthey look like regular payments.\n\nOne down side is that this would essentially double the size of HTLC\nmessages on the network today, as they need to also carry SURB.  Most\ncandidates for possible rendezvous schemes to deploy would also increase the\npacket size if up to 20 hops it be allowed in both directions.  We also\n(from my PoV), don't really have a feel on how much of an issue the 1.2KB\nHTLC packet size is today in the network.\n\nBy re-introducing SURBs, we have an opportunity to cleanly solve the payment\nACK issue, re-use a component of our favorite thing in Lightning, enable\nprotocol-level streaming/subscription payments and also make replies\nindistinguishable-ish from regular payments.\n\nThoughts?\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190207/77cde3d7/attachment.html\u003e"}