Tbh I'm scared to #zap over 1M sats for the simple fact, I cannot verify if the recipient can even receive that large of a Lightning payment
Don't want sats to get stuck anywhere.
Solution? Run own node with own self-hosted Lightning@Address
Tbh I'm scared to #zap over 1M sats for the simple fact, I cannot verify if the recipient can even receive that large of a Lightning payment
Don't want sats to get stuck anywhere.
Solution? Run own node with own self-hosted Lightning@Address
Have you ever seens sats get "stuck" on lightning? I've never heard of that.
Yes. Doesn't happen nearly as often as it used to
I'm moreso talking about the smaller LUD-15 providers with a smaller lightning node; minibits and other like that come to mind.
Your strike, bitrefill or Alby Lightning@Address would be more than fine imo
What happens when theyre stuck? And whats LUD-15?
Sorry, LUD-16 (standard for implementing lightning addresses)
They get stuck by constantly trying to find a route, and it keeps failing. If you close the sending and/or receiving wallets, those funds could be identified as "spent" when you reopen, or on the other end, "still pending" and not received.
If the app stays open, the payment just times out and records that failed payment.
Never close your lightning wallet when sending a payment. Or receiving one.
Learn more about the spec's of LUD-16 and all other LUDS hereπ
Actually just had this happen last week; buying miners with Lightning (forgot already lol)
Over 1M sats got "stuck" for over an hour because the receiving node didn't have enough capacity. Sending from my phoenix wallet, I needed to keep it open to make sure the payment could be returned if it didn't go through within the timeout period (3600 seconds)
Again to me, these are rare scenarios which rarely occur, because most people aren't sending phat lightning payments and trying to get them to route.