Could possibly add a split payload to CLINK offers responses that loads n additional invoices or offers for other parties. The primary offer publisher is still trusted to serve those though, but, never holds the funds themselves.
Alternatively, chain n offers together into one string, with a delimiter where clients sequentially pay each. Biggest issue I see with that would be the strings become extremely long and ugly and it wouldn't work with QR codes
The latter would probably work fine in shops UX's specifically though, assuming there was a debit wallet connection to handle the long strings without QR scanning/copypasta
The issue is that Lightning itself can't natively split payments so it's ultimately always going to be some hacky way of sequencing multiple payments that aren't atomic.
Open to other thoughts, the latter is a trivial CLINK/SDK addition with no work on the reference server and I can tinker with it in our in progress shops UI on Bxrd.
Login to reply
Replies (1)
> Lightning itself can't natively split payments
I think it can. If the wallet knows it wants to pay 400 sats to Alice, 300 to Bob, and 500 to Carol, it can arrange a route that passes through each of their nodes, and drop pending fee htlcs off at each one, whose value corresponds to the amount desired for that node. The last node reveals the preimage and then everyone gets paid. That's an atomic split payment that lightning has native support for.