lightning
Additional auxillary data for HTLCs
For stateless payments, we often want to include information about an offer/invoice-request in the blinded path we return in an invoice so that we have the info after the sender has (finally) paid their anti-DoS token with an HTLC. Thus, we keep finding ourselves trying to add additional data back in the payment onion but struggling with its limited size. While increasing the size of the HTLC onion (ignoring compat concerns) isn't a very good idea as it allows for more loops and additional liquidity DoS concerns, that doesn't mean we can't add a second "auxillary data" onion in update_add_htlc messages.
There's obviously upgrade/rollout concerns, but assuming we are willing to wait, are people open to such a thing? It'd mean somewhat larger update_add_htlc messages and additional storage overhead for each HTLC between receipt and forward, but having an extra KB or five of data space without preventing someone from sending an HTLC over five hops would be quite nice. Thoughts?
anti-DoS token
Anti-DoS token?
What would be in this extra onion? If a peer doesn't understand the onion, can the payment still be completed?
Anti-DoS token?
eg someone might include some information in the BOLT 12 invoice_request that we want to have when we receive the payment, but we don't want to store that information in a DB immediately, as otherwise someone can just flood us with invoice_request messages and bloat our DB. Instead, we want that information to go in the blinded path, so that when someone pays with an HTLC we get the data back and can store it after there's no substantial DoS risk (which I referred to here as the "anti-DoS token" cause them actually paying is a reasonable way to provide anti-DoS :) ).
What would be in this extra onion?
Presumably just extra payment metadata from the blinded path.
If a peer doesn't understand the onion, can the payment still be completed?
Upgrade would be painful, yea, you'd have to only store optional data there and old nodes would drop it during forward so relying on it would be a thing that can only happen in a few years.
This would be very useful for us, but if it's not reliable for a while we'd have to persist the metadata anyway, and since it's a few years out by then we will already have all this infrastructure built. Maybe it would save future wallet developers some headaches.
