Oddbean

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.

I think stablecoins on lightning will be a nice stepping stone for people that want stables as most people's bills are fiat based. long term we won't need them. My main reason for not switching to CLN a year and a half ago when I ran a test CLN node is channel closings and reopenings. I just don't want to waste the sats.

that's fair. admittedly I am a complete novice when it comes to LN node running (only just stood up one in the past couple of months). I mainly base my CLN maximalism around a couple of things: 1. tech stack - CLN is C/Rust where LND is Go. tech stack flame wars are always fun and I've picked my side and it's oxidized. 2. focus - LND creators are focused on building a bridge to a failing system with stablecoins. conversely, it seems like those working the LDK/CLN side are building rails for the future. 3. I've just tangentally heard about more issues impacting those running LND nodes than any other. this could very well be bias due to volume of LND vs CLN on the network but my gut tells me otherwise (again, could be my tech stack bias mentioned in 1.) both are needed. everything is good for bitcoin. we're winning. code is law of the future.

Rust is promoted by Mozilla and 90% of shitcoin projects are also working with or adopting it, so that is irrelevant. not to mention what a terrible design it has for memory management, for a minimal benefit compared to Go and a huge complexity in learning compared to C++. the btcd/lnd codebase is a mess, and an embarrassment to any competent programmer. see my previous comment regarding the state of it, and my experiences with trying to contribute to it.

Nah, imagine if there was only one LN implementation and only one group of people calling the shots. That would suck IMO. I'd rather see things get hashed out appropriately rather than steamrolled.

Thanks for someone with clout pointing out the abuse Zeuspay is performing here. nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtspzpmhxue69uhkummnw3ezuamfdejsygxlzue8wxp0x92ax7enqggm580y4q2spspdr90fvnu3hem5ajt8pqpsgqqqqqqsts2yna

Their full focus is on TapAss - Taproot Assets. It’s a copy of the RGB project implementation with VC money behind it This is what you get when big VC money is behind one specific protocol implementation (LND) Objective is USDT on LND which could enable the biggest trading pair BTCUSDT volume to move off exchanges and down to a protocol level

Oh...didnt realize turning off payments to rivals was a thing...or that Zeus's methods aren't universally accepted as the best. Learned a lot in this post. I guess one sort of rugging is more acceptable than another. nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtsppemhxue69uhkummn9ekx7mp0qgsd79ejwuvz7v246danxqs3hgw7f2q4qrqz6x27je8er0nhfmykwzqrqsqqqqqpmuv7lm

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.

What's next for Mutiny? Get together with FinCen and limit payments to all other LN implementations? What kind of "non-custodial" wallet is this if the LSP will do this move against all its users?

The're just trying to protect their users. Also: nostr:nevent1qqs2d5q8f9c4tmzvrzg47d0gn7pdhhzjtc45d7dpp5x22v8zesf8pcgpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqgvra9r4sjqapufyl0vnc4kv4fz70e29em4c655y37vz206f0wt4qvzqqqqqqywaj8kk

Frustrations are creeping out... nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtspzpmhxue69uhkummnw3ezuamfdejsygxlzue8wxp0x92ax7enqggm580y4q2spspdr90fvnu3hem5ajt8pqpsgqqqqqqsts2yna

Free markets are dope 🤙 Competition ftw nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtspp4mhxue69uhkummn9ekx7mqzyr03wvnhrqhnz4wn0vesyyd6rhj2s9gqcqk3jh5kf7gmua6we9nssqcyqqqqqqg6jh92l

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. nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtsppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprpmhxue69uhkummnw3ezuendwsh8w6t69e3xj730qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq3samnwvaz7tmjv4kxz7fwvd6hyun9de6zuenedyhszymhwden5te0danxvcmgv95kutnsw43z7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcwne7ch

It has the same throughput problem like Bitcoin, but has no L2 network yet. At the moment it’s not a problem at all, but it will become one, so we will need something like Lightning Network as well.

With a large burst of demand, in the short term, the fees could spike on Monero, but long term the fees would continue falling even if the demand was sustained because of dynamic blocks. The same thing cannot be said of bitcoin. Fees will rise with demand long term and will not fall because blockspace is limited and inelastic.

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.

This a red line for me. I won't be censored. I would gladly eat force-closures and frozen liquidity for a while, it's just growing pains on an experimental wallet on an experimental network (which LN still is). Bye mutiny! nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtspz9mhxue69uhkummnw3ezuamfdejj7q3qmutnyacc9uc4t5mmxvpprwsauj5p2qxq95v4a9j0jxl8wnkfvuyqxpqqqqqqzv4rpqs

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. """

It's still the difference between trusted vs fully custodial by a single actor. And as a fedimint module, this is a service they will be doing on behalf of users anyways. Not meant for an additional third party.