Thread

We have recently disabled the ability to zap @ZEUS 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.

Replies (55)

their taproot code is taken from decred's codebase, for one thing. it doesn't have full implementation of BIP-340, despite this, it fails on the last 4 tests in the suite, and i fixed it and pointed them to it in an issue but i got some dodge from roasbeef about why they didn't properly implement the tests. (for irregular length message signing). as a Go dev trying to work with bitcoin and lightning their BTCD and LND codebases are a shitstorm of stupid. the damn btcd has dependencies to prior versions of itself, just for starters. the configuration system on both btcd and lnd doesn't work. i've tried to put some PRs up to get a few things fixed but they never merge them. even tried to chase an actual issue they had filed, that issue is still there, the patch is still dangling, and would take about two hours to merge in.
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. View quoted note →
Guys, your devs were (indirectly) calling me incompetent earlier, but publicly dunking on your colleagues like this is not a sign of great professionalism. Go ahead and make those missing features instead like I was actually trying to do back in the day.
Re: LND's continued priorities on shitcoins I think post author is referring to LND's Taproot Assets (a.k.a Taro) Here is from Lightning Labs recent newsletter (August 2023): """ Over the next year we will also probably see more APIs added to support the Taproot Assets project because that will be built on top of LND but not be tightly integrated internal to LND, similar to the Faraday, Aperture, Loop, and Pool projects that are part of the extended release bundle. A new PR adds a new signing API needed by that project: "add schnorr_sig_single_tweak option to msg signing" - Github issue 7898 The Taproot Assets integration is also expected to have a heavy impact on the Taproot channels implementation so that the asset control can be handled by an external daemon. These APIs will allow for a clean separation and conceptually there could even be multiple competing Taproot Asset daemon implementations that would all leverage the same API interface. """