Whoever is implementing lnpay.co - for the keySend you can now send an extra header "X-LNPAY-ASYNC: 1".

This took my call down from 18 seconds to 2.

I am still a bit concerned how it will scale, but I guess Tim will be motivated to fix it if we break it :)

( @dellagustin @adam @dave @hypercatcher )

@martin @dellagustin @adam @dave wow, that’s good to know. I’ve never seen it take longer than a second in my testing from postman, but I know if the path finding to the node takes a while it could take a while I suppose. Are you testing sending to your own Node or to a LNPay wallet?

@hypercatcher @dellagustin @adam @dave

Testing with the people in the podcastindex.org value block, so that's Adam, Dave, Dreb and the PodcastIndex. The total of those 4 calls are taking anywhere between 13-18 seconds :/

I haven't actually tested if it's just a single one of those that's taking a really long time, that could be interesting to test.

@dellagustin @hypercatcher @adam @dave I think basically it just doesn't wait for an answer, so your connection isn't hanging. Which can be both good or bad of course.

He did say that he would think about making a batch endpoint if it doesn't scale once more users get's on board.

@martin @hypercatcher @adam @dave yeah, not knowing if the payment was successful at the end comes with its own problems. I wonder what would be the throughput of a single node in transactions per second...

@dellagustin @hypercatcher @adam @dave I don't know if I actually need to know if it was successful or not.

Like if it's not successful what would I even show to the user? I would probably just treat it as a temporary error anyway.

@martin @hypercatcher @adam @dave If it is not successful, I will put that amount back in the balance that has to be transferred to that destination and try again next time, but if you don't know whether it was successful, you don't know if you are paying for that amount of listened time.

@dellagustin @hypercatcher @adam @dave That is a good point. For me I don't think I will necessarily make those kinds of state. If it fails then "eh, will probably succeed next time". I don't see it as super critical if a few micro payments fail. (Boosts are different of course)

@martin @hypercatcher @adam @dave I considered state from the start because of the routing fees, if you transfer 2 or 3 sats and have to pay 1 sat of fee, at the end it is a 30 to 50% fee, so that is too high. LNPay still does not have a max fee, so I am considering adding an option for minimum transaction amount.
Also, I have a background in payroll software, so ensuring people have paid is probably in my blood already 😜

@martin @dellagustin @hypercatcher @adam I honestly would ignore a failed per-minute payment, like a dropped packet with internet routing. If a boost failed I would want to know and re-transmit that.

The honest truth about Lightning is that keysend payments will sometimes fail. It's a store and forward routing network, so that has to be expected.

@dave @martin @dellagustin @hypercatcher I concur. Much like ICMP, we drop one from time to time. Multi Path Payments will probably solve some of this. They are in LND 12.1

@martin @dellagustin @hypercatcher @dave The index node was down. This could have affected routing and most certainly payment. As we simple could not receive for about an hour. Hence my post earlier 🙂

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.