pull down to refresh

I wonder why LDK wallets are kind of abandoned. I saw some of them that are 3 years not updated.
The only one that see maintained well is Alby Hub.

Another working one is BitKit.

Do you know more of them? Working and maintained not abandoned.

193 sats \ 6 replies \ @supratic 12h
  • CashApp is built with LDK
  • Fedimint (was?) using LDK, not sure it's for the mobile app or for the server application
  • LEXE is actively maintained and lately has been making some noise lateley
  • kumuly.dev last update Apr 2024, but worth to mention
reply

Never heard of lexe

reply

cashapp and fedimint are out of discussion.
Lexe I know about them, yes worth mention it.

reply
cashapp and fedimint are out of discussion.

Why?

reply

custodials and not native LN nodes.

reply

Coinos is a great LN wallet if you are not a technical snob and want to participate in the BTC P2P V4V circular economy on Stacker news.
By using sats P2P everyday on SNs and Predyx you are supporting the LN infrastructure of nodes, wallets and communities.
By refusing to attach wallet/s @Darthcoin is undermining the strength and development of the LN.
His elaborate elitist philosophically pure self custody nodes and wallets sit in the corner, unused, gathering dust, and watching the LN die, for lack of use.

reply
0 sats \ 0 replies \ @mo 5h

deleted by author

Beware alt-implementations of Lightning nodes (bad), its far riskier than alt-implementations of Bitcoin itself (good)

#1317912

reply

Are you saying LDK is the issue?

reply

I'm saying that the FUD that often comes up when discussing alternative implementations of Bitcoin re: Core's monopoly are backwards.

Alt-implementations on L2 are dangerous due to it's highly coordinated nature and the cascading effect, that's not the case on L1.

By operating any minor lightning implementation, not just LDK as there at least 2 others, you face undue operational risk vs sticking with the prevailing implementation.

reply

True, building on top of the giants shoulders is always safer. But in this case how from your perspective, smaller implementations like LDK can thrive?

reply

In that thread I get into the incentives of Lightning implementations being different than on L1, I see no escape from this at present.

Every Lightning implementation serves its creators as distribution or scaffolding for other services, which isn't the case with alt-L1 implementations.

  • LND for example has a suite of stuff that hooks into it like Loop, TapAss etc.
  • Eclair itself is part of Phoenix's own LSP offerings
  • CLN is a part of the Greenlight service
  • LDK likewise is doing something similar to greenlight with "serverless" nodes and thinclients for CashApp's centralized exchange

So these aren't keeping consensus monoculture in-check like an L1 imp would, nor are they strictly being used as libraries to enable purpose-driven shells.

This delivery of ancillary services is a mal-incentive, as we've seen with hostile specs like Bolt12, where the minor and largely irrelevant implementations must dilute the protocol with trash in effort to gain share.

What a minor implementation needs to do to thrive is be purpose driven, "in Rust" is not purpose, bundling an LSP is not purpose, experimental new features should be a fork of the prevailing implementation, and challenging monoculture should be an LND-derived library. None of the minors have a clear stand-alone purpose.

If I had unlimited resources to shepherd an alt, it's purpose would be to decouple implementation from services. That would be a fork of LND that strips it down the essentials, making it both compatible with the network, and more flexible for ancillary services to build on. Once that kernel of sorts is functional, only then would I port to other languages with the sole emphasis being compatibility with what's prevailing regardless of the specs.

LDK does at least pays lip-service to this library model, which is good, but it's scope beyond that makes it ineffective at doing so. Complete re-imp in Rust is a disaster, and so they still try to influence LND to make their shit work. The NGO behind it is hostile, and the services they build on top of it are the ultimately dictate of roadmap. They're not simply making a better or more versatile implementation.

reply
0 sats \ 1 reply \ @supratic 6h

gotcha, staring point is the wrong one. Your approach make sense and I guess could provide much more value to other developers and engineers coming form outside-bitcoin spaces.

Interesting is your take on the incentive structures here. What would count as a "real" standalone purpose though? Would something like "optimized for embedded systems" or "hardened against specific attack vectors" be enough, or is that still too vague?

Where you'd draw that line?

reply
What would count as a "real" standalone purpose though?

I think philosophical adherence to the model of L1 implementations

On L1, implementations exist to enforce/comply with the same rules.

(Core's monoculture has been deviating from this principle, hense the blowback, and rising interest in consensus libraries upon which to build new distributions)

On LN, implementations exists to capture users into an ecosystem of liquidity infrastructure and routing flows, hense protocol pollution and compatibility issues.

So the purpose of something new needs to be that its vertically neutral and consensus driven, therefore reusable into disparate distributions. Hardened surfaces or embedded use-cases are too specific, both would ideally be unique distributions of the same implementation.

I think CLN missed an opportunity here as they were on the scene at roughly the same time of LND, and the plug-in model was aligned to re-usability. LND hadn't built out its larger ecosystem yet, it just out-executed by being more developer friendly and active. I think the choice of C was a bad one as its hard to approach, Go was easier to build a network effect of community developers with. Blockstream was also never all-in on Lightning, they're primarily a Liquid shop.

It's LND's success in gaining overwhelming share enabled the larger ecosystem that its now optimizing for, though that was probably always the sustainability model. The problem with a new implementation, or a fork of LND, is it basically has to have no sustainability model.

reply
21 sats \ 1 reply \ @trieska 5h

@DarthCoin is this article #155848 still actual or something has changed?

I am asking because I have bitkit on todo list, I would like to try. And now you are saying that another working LDK wallet is bitkit. So I am little bit confused. thanks

reply

Yes, Bitkit fixed that issue but they still behave strange. Also the wallet policies are really weird. If you want to play around to test is OK, but for long run I suggest caution.

reply

'I wonder why LDK wallets are kind of abandoned. I saw some of them that are 3 years not updated.
The only one that see maintained well is Alby Hub.'

Maybe they are abandoned because people are not using them enough because despite having opportunity to use LN frequently on SNs some lazy hypocrits who claim to be bitcoiners nevertheless refuse to attach their wallets to SNs and so boycott the opportunity to use their LN wallets on a regular basis which will support the upkeep of the wallets and the nodes via fees paid on multiple LN transactions.

Systems die if they are not used and supported and @Darthcoin is refusing to support the P2P V4V BTC circular economy on Stacker News.

Attach your wallets to your SNs account to support the upkeep and development of LN wallets and the BTC p2p circular economy- and STOP being a hypocrit.

reply

@Darthcoin is refusing to attach LN wallets so do not send him any sats because he is a technocratic arsemilking hypocrit.

@DarthCoin claims to live on the bitcoin standard but in reality refuses to even attach a LN wallet here on Stacker News...the great BTC Maxi who claims he 'lives on the BTC standard' claims attaching his wallets would cause too much stress on his nodes.

Calling out the gross hypocrisy of @Darthcoin

Do not zap this arsemilking hypocrit.

reply