Super Testnet on Nostr: As the guy who made the spec that Zeus Pay is using to enable async payments, I ...
As the guy who made the spec that Zeus Pay is using to enable async payments, I support Mutiny's decision. I think disabling payments to destinations that are known to use hodl invoices is the right move for mobile nodes until some method for mobile nodes to safely pay them is discovered.
Right now a mobile node cannot safely pay a hodl invoice without risking an expensive force closure. But this also exposes a griefing vulnerability that mobile nodes are susceptible to. Nodes simply cannot tell the difference between a hodl invoice and a normal invoice. But if they do pay a hodl invoice, and then go offline for more than a day, they are likely to get force closed, which costs them money.
Since these "dangerous payments" are indistinguishable from safe ones, it is easy to grief someone if you suspect they are running a mobile node and are`on a regular zapper: get them to zap you, hodl their payment for about 10 hours or so, and then settle it. There's a good chance you'll put them in a force closure state at no cost to you. Which means *all* mobile nodes are dangerous to use for zapping right now. You can easily get burned.
I am grateful that Zeus exposed this problem and I look forward to thinking of more/better mitigations than trying to block all hodl invoices whack-a-mole style. That might work fine in a non-hostile environment, but I suspect we're heading into dangerous waters on lightning. Here there be trolls. Watch yourself.
Right now a mobile node cannot safely pay a hodl invoice without risking an expensive force closure. But this also exposes a griefing vulnerability that mobile nodes are susceptible to. Nodes simply cannot tell the difference between a hodl invoice and a normal invoice. But if they do pay a hodl invoice, and then go offline for more than a day, they are likely to get force closed, which costs them money.
Since these "dangerous payments" are indistinguishable from safe ones, it is easy to grief someone if you suspect they are running a mobile node and are`on a regular zapper: get them to zap you, hodl their payment for about 10 hours or so, and then settle it. There's a good chance you'll put them in a force closure state at no cost to you. Which means *all* mobile nodes are dangerous to use for zapping right now. You can easily get burned.
I am grateful that Zeus exposed this problem and I look forward to thinking of more/better mitigations than trying to block all hodl invoices whack-a-mole style. That might work fine in a non-hostile environment, but I suspect we're heading into dangerous waters on lightning. Here there be trolls. Watch yourself.
quoting nevent1q…e7chWe have recently disabled the ability to zap ZEUS (npub1xnf…lpr5) wallet users from Mutiny. You may still pay their invoices or LN addresses normally but a big problem we were seeing was force closed channels due to stuck payments to Zeus due to their work arounds with locked payments. Which harm both the user experience and other lightning nodes on the network.
Since nostr users are mostly unaware if they're zapping Zeus users or not, we are taking this step proactively to protect users from having a 10 sat zap costing them serious on chain channel closing (and reopening) fees.
The approach we are working on for solving lightning addresses on mobile wallets is a fedimint hybrid approach where the sats end up at a federation if you are offline but get swept to your self custodial channel when you come online. Payments will settle instantly with the federation and it won't lock up unnecessary HTLCs on the network.
Ideally we get the ability to do offline receives normally on LN but that future is looking really grim with LND's continued priorities on shitcoins instead of features, and offline receives depends on a network wide upgrade.
We petition Zeus to move to a more responsible node implementation like LDK unless their plan is to add shitcoins or break LN further.