I don't see anything wrong with this. Alice is locking funds to Carol's secret, which is no different than routing an HTLC.
In practice, wrapped invoices will probably scale very poorly. This is because the lightning node for Alice will only consider routing to Bob, and the lightning node for Bob will only consider routing to Carol. The route will not be optimized at all.
The solution for this of course is to to build a Bolt 11 invoice with all your Bob nodes specified in the route. Then the path-finding logic for Alice's node will try to build an optimal route.
For some reason, LNURL doesn't implement the routes attribute from the LUD-06, even though it is named in the spec. It would be nice if it did, because then you could specify members for a multi-party payment.
However, this still doesn't solve the problem, because adding Bob to the route doesn't mean that Bob will know to intercept that invoice, and charge a certain fee.
So then what you need is an HTLC interceptor, that is looking for a specific payment hash, so that Bob's node can charge the correct fee. But I'm not sure to what extent you can get away with this, as you may have to mess with your node's pathfinding API, and every implementation is different.
So in addition to the above, you may also need to analyze the graph and build the route yourself, then have your node setup the HTLC, then pay the invoice.
Much of the above is pure speculation and I may be completely wrong.
I have also thought about this problem quite a bit myself 😅
In practice, wrapped invoices will probably scale very poorly. This is because the lightning node for Alice will only consider routing to Bob, and the lightning node for Bob will only consider routing to Carol. The route will not be optimized at all.
Yep, routing failures compound, but if LN is to succeed, this kind of thing should be as reliable as sending your traffic through a VPN.
The solution for this of course is to to build a Bolt 11 invoice with all your Bob nodes specified in the route. Then the path-finding logic for Alice's node will try to build an optimal route.
If it's all done in a single route, I don't think this is any different than the wrap actually. But, if Alice can split the payment on multiple routes, one going to Bob and another to Carol, it'd provably be more reliable because each route requires less liquidity. It's like MMP then.
However, this still doesn't solve the problem, because adding Bob to the route doesn't mean that Bob will know to intercept that invoice, and charge a certain fee.
It depends on the problem you're trying to solve. If Alice pays Carol and Bob independently, but Bob only wants to accept the payment if Carol receives her payment, he can hold Alice's payment, cancelling it if Carol isn't paid and accepting it if she is.
reply
With PTLCs you should be able to split payments like that. You could lock an invoice to the sum of a set of invoice secrets, for example (since points can be added).
reply
Ptlcs seem to be a big unlock for all kinds of stuff. Maybe we’ll get it after bolt12
reply