pull down to refresh
110 sats \ 2 replies \ @k00b 17 Jan \ on: Semaphore.finance now has lightning support bitcoin
I know Super knows this because we've talked about it before, but the only way to do this is to be on the payment route. One of my biggest pie in the sky wishes in service of Lightning apps is atomic payments to multiple recipients that somehow doesn't rely on recipients being along the route.
Naively, recipients would have to coordinate and possibly even have a contract between each other, which eventually begins to look like a lightning channel (surprise), but maybe there's some other clever way.
the only way to do this is to be on the payment route
I'm not willing to say certainly that it is the "only" way. But it is one way, and I think it's pretty neat, and possibly good enough, if some elbow grease is put into making it work well
[I want] atomic payments to multiple recipients that somehow [don't] rely on recipients being along the route
Correct me if I'm wrong but I don't think you are inherently opposed to each recipient being on the route, I suspect you just see that as bringing additional challenges that you don't know how to overcome. Some of those challenges include:
- cell phone users are probably not along the route because they are probably not running routing nodes
- I think you could solve that by having each cell phone user "temporarily" act as a routing node but then you face the following two additional problems
- a cell phone user probably doesn't have enough inbound and outbound liquidity to forward the payment to the next guy
- if a cell phone is part of the route, it would be just awful if they were offline when you're trying to do the payment
I think with some elbow grease those challenges are overcome-able. Just-in-time-routing is pretty magical if someone is online, and if they are definitely offline, zaplocker demonstrates that an intermediary can atomically hold a payment for someone til they get online to collect it, without taking custody.
Someday I'd like to see how close LN can get to "one sender, many recipients" using those tools. The sender's device could figure out which parties are online and construct a route "though" them using just-in-time routing tools, if necesary, to ensure everyone has enough inbound and outbound capacity to do their part, and if someone is definitely offline, it could send their payment to a zaplocker server as a kind of docking station, knowing that the server won't be able to keep the funds, but they'll either return to the sender or go to the recipient when they next get online.
reply
I don't think you are inherently opposed
Correct, it's just inconvenient.
I suspect you just see that as bringing additional challenges that you don't know how to overcome.
At least for the challenges I'm immediately concerned with, I know how to overcome them.1 However atomic splits done this way require each intermediate recipient have:
- incoming liquidity equivalent to
- their share of the payment
- the shares of recipients later in the route
- outgoing liquidity equivalent to
- the payment shares of recipients later in the route
In addition to being reliably online.
Footnotes
-
I think about this problem in the context of taking an SN-like sybil fee, ie a third party verifying a payment happened and taking a fee without additional interaction from the sender and receiver. The third party can do this by "wrapping" a bolt11 from the destination in a hold invoice paid to itself. This would work for multiple third parties too with each wrapping the bolt11 of one of the other third parties. ↩
reply