Replying to Avatar OpenSecret

We have recently disabled the ability to zap nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 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.

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.

Reply to this note

Please Login to reply.

Discussion

> as a Go dev trying to work with bitcoin and lightning their BTCD and LND codebases are a shitstorm of stupid.

as a fellow Go dev I probably spent a total of 8 hours trying to orient myself in the LND codebase and came to the same conclusion.

i made a few things to get around needing to import their pile of crap repository and its dependency hell at https://github.com/mleku i mean, decred. come on.

you had me with the table tests in bech32 ๐Ÿ˜

yes, i did all that because it's needed for nostr. the rest of btcd code can be avoided if nostr is your main target.

Lightning is not so easy to avoid the insanity. https://pkg.go.dev/github.com/lightningnetwork/lnd/lnwire

check the version and date on that.

they haven't fixed this, yes i filed an issue, about a year ago, and if you naively try to import lnwire, for, things ilke, you know, millisats units, hoooeeee. lol! have fun staying extremely frustrated at go mod tidy.

LND/BTCD devs need to be shamed for their terrible custodianship of the main Go codebase.

the fact that itโ€™s not a standalone go module and forces you to drag in the dependency hell that is lnd is insane.

i hope to some day in the future fork and fix these projects. for now just going to chip away at it whenever it is needed.