Is LND (Lightning Labs) ruining the Lighting Network? \ stacker news ~bitcoin

Is LND (Lightning Labs) ruining the Lighting Network?

13.4k sats \ 71 comments \ @Krutus 8 Jan 2023 bitcoin

I know, little bit "clickbait" title but I want to get some attention.

To be honest, I've been pissed off by the behaviour and further development of LND by Lightning Labs. Why? They don't care about specification and compatibility with other implementations and prefer solutions that will benefit only them. As a result, the Lightning Network will not be as successful as it could have been if they had worked together with other teams. I will explain...

There are 4 main players today in Lightning Network:

LND by Lightning Labs
Core Lightning by Blockstream
eclair by ACINQ
LDK by Spiral

LND has 90+ % of the market share, which probably gives them the right to decide on the future development of LN even if other teams and most of the community are against it.

There is a tweet from Alex Bosworth, where he is suggesting inbound routing fees. Quite a change, isn't it? You say to yourself that surely there is a specification for this and it has been discussed with others. Reality? Quite the opposite.

Matt Corallo (from LDK team) is against it, the same applies to Rene Pickhardt and Rusty Russel. But "fuck the collaboration and specs", we have 90+ % of market share and there are some big nodes using LND...

And it's not just about this one thing. There are a ton of improvements, that could improve the Lightning Network as a whole. The other teams (Blockstream, ACINQ, Spiral) are working on them, rolling out the specs and testing them together. Whereas Lightning Labs is going along its own that benefits them and not the network as a whole. Some examples:

We're big, we can do whatever we want

Here's part of an email from Alex Bosworth where he claims that if other implementations don't have the market share they do, they have no say in the specification. You can also find there what others think about it... Moreover, a lot of nodes run on mobile phones and are not in these statistics.

New features come before stability and security

You are probably aware of the critical vulnerabilities in LND recently (specifically in the btcd library) that led to nodes not being synchronized with the blockchain and potentially losing resources (which fortunately did not happen). What would you expect? For example, that they would apologize and do their best to make sure it doesn't happen again? Instead, Lightning Labs CEO Elizabeth Stark accused Blockstream for sponsoring the attack. Sure, she then deleted the tweets and apologized, but... Wouldn't it be better to admit a mistake than kick around? Not to mention that a similar bug was repeated again a few days later.

Watchtowers

There is a open specification for watchtowers (BOLT-13). Wouldn't it be great if there was a uniform standard? And what did the LND do? Their watchtower is a proprietary solution where the watchtower itself is another instance of LND. A great solution if there is a bug in LND (see paragraph above) and then even watchtower can't save you...

Liquidity

CoreLightning has introduced liquidity-ads. A clever and fully decentralised solution where bids to open channels are propagated through the gossip protocol itself. No need for any trust, service or centralized server. LND's solution? We will not support liquidity-ads (although ZeroFeeRouting has offered money to whoever implements it in LND) as it competes with our centralized solution called Pool, which we profit from.

BOLT-12

Everyone is expecting BOLT-12 and other implementations already have it deployed and testing it. LND approach? We're not going to implement it, for now.

Other things

There are a lot of other great improvements here - route blinding (privacy improvement), trampoline routing (simplifying routing for mobiles), async payments (ability to receive payments even when I'm offline), PTLC, a solution to the channel jamming attack, eltoo (although we're waiting for the Bitcoin modification here), etc. Most other implementations work on these in some way. And how does Lightning Labs approach this? What is their roadmap? Completely different, unfortunately...

Summary

I understand that their priorities are different because they are VC-funded and and therefore has to make some money. Preferring proprietary and centralized solutions that they can somehow profit from, coupled with the fact that they'll skip writing specs and communicating with other teams because they have a large market share, so they'll decide everything, is not the way to go in my opinion.

This is not meant to be some attack on Lightning Labs, and I believe there are a lot of great people working there. I just wanted to make my point that I don't like where their development is going. Either they will force others in this way or after a while we will have two separate networks - free and open-source running CLN, eclair and LDK and then proprietary with LND...

The only thing I can (and will) do is ignore the pretentious nonsense from Alex Bosworth and replace my LND node with Core Lightning.

view all related items

500 sats \ 3 replies \ @TonyGiorgio 8 Jan 2023

Careful what you wish for. As @benthecarman said in this thread, it's really miles beyond any other implementation. I don't like any of this as much as the next guy. But as a developer building custom lightning solutions for a living, it really fucking sucks to build on anything not LND unless you're so expert that you can manage LDK and build your own node implementation with it, but that's not a walk in the park either.

Running CLN is one thing if you can figure out (and really test your backups after reading the ~50 page document on backup procedures). Developing on it is a different story. I'm working on a project just using 6 or 7 API calls and none of that shit even works and the lack of support or care from the couple people that kind of work on it is frustrating enough to question "well then why would I even build on it". It'll cost millions of dollars for a serious project to switch to CLN. It's best at that point to hire experts to build your own impl on LDK at that point.

I don't want to hear about people's hobby projects building on hobby CLN, or someone that used CLN to open a few channels that barely do any routing. Try doing something serious. Ask ZFR how it ended up for him and if he even got his funds out of his channels correctly...

78 sats \ 2 replies \ @ab 8 Jan 2023

I guess the project I am working on (Clams) counts as a hobby project as it is not used at any real scale ATM, but I found that all of the CLN Rest API's are easy to use and are reliable. I also have found that the CLN team are all super responsive on their discord and are very generous with their time when I needed help with anything.

I was previously building a project on LND and I think the docs are definitely better, and I had helpful and quick responses from their devs in their Slack as well.

So overall I would say that both implementations currently have a similar dev experience.

I chose to build on CLN as I think they are prioritising better features (Bolt 12, Liquidity Ads, Bookkeeper) and I would like them to have a greater share of the network. Having 90% of the network using one implementation is not good for the network as a whole IMO.

44 sats \ 1 reply \ @TonyGiorgio 9 Jan 2023

Yeah I mean there's nothing wrong with the "hobby project" stuff and I think your project should be a good one to work on. It's just like - I'm tired of the argument of "oh I did a few things with CLN before and it's great, everyone should switch to it because F LND".

Projects which are mostly just meant to proxy calls to CLN itself, like yours, should probably have a decent experience. You're a window into the actual CLN API. And for people that simply want a node to be there and do a few things like pay and receive occasionally, it's not the worst thing in the world to use. But It's no question to why LND has and will probably continue to have majority nodes for quite some time further.

Building a business on top of CLN is just a way different story, maybe one that people don't care about, but if it's easy for a business to do, then it's easy for a normal person to as well, IMO. Needless to say, I don't have high hopes for their greenlight project either and I really wonder if Roy will question going that direction with Breez as time goes on. It's quite ironic since LND has ended up implementing many of the features that Breez has been waiting on for quite some time. Too little too late maybe, and the direction of LL is questionable, but pick your poison I guess.

12 sats \ 0 replies \ @ab 9 Jan 2023

Yeah I agree it is not as simple as F LND. We are all Bitcoiners here at the end of the day, we are on the same team and we should strive for a collaborative rather than combative environment as we are fighting an uphill battle against the incumbents as it is.

Have you written down anywhere the pain points you ran in to when trying to build a business on CLN? I would personally be interested to understand what you mean and my sense is that the CLN team would value that feedback. Things that come to my mind for enterprise businesses would be the ability to run a cluster of nodes connected to the same DB for failover options, but I believe the Postgres backend looks like a good option there, but admittedly I have not tried that option before. Previously CLN seemed to be better in regards to DB size (reason for zero fee routing node to switch i believe) but my understanding is that LND has made improvements to catch up on this in recent releases. So yeah curious on particularly what you found a show stopper in CLN integration.

I like the idea of Greenlight and have high hopes for it. It is yet another way people can run nodes and I like that there are so many options with different tradeoffs that suit different situations. I am curious in the long run if there will be a power law distribution on how people run nodes. Will it mostly be full mobile nodes, will it be node in a box solutions, will it be cloud nodes or a combination that is reasonably distributed? I look forward the Breez/Greenlight solution as it feels like a great set of tradeoffs for most average users, but let's see!

413 sats \ 1 reply \ @vnprc 9 Jan 2023 freebie

You forgot about that time LL deployed keysend payments with no spec. C-Lightning devs had to reverse engineer the feature in order to write the spec and a compatible impl.

Labs was made in the Silicon Valley mold: raise a shitload of VC money, hire the biggest and best engineering team, race to build the best developer tools, lock out the competition, and capture the market. Once you have captured the market (they have) leverage your monopoly power to squeeze out other impls and expand your monopoly. Embrace, extend, extinguish.

If you are a lightning dev ask yourself if you want the future of decentralized payments to go the same way as so many other markets that have been captured with this model: email service provider, internet search, web browser, video sharing, etc.

Monopolies are bad for free markets but good for monopolists. Which one do you want to support?

1321 sats \ 0 replies \ @03bebce944 10 Jan 2023

deleted by author

1061 sats \ 7 replies \ @hampus 8 Jan 2023

This is a very popular narrative, but it's just not true.

Lnd is collaborating with the rest, including on some of the things you listed in the post. As an example, BOLT12 is actively being developed for Lnd by Carla Kirk-Cohen, an ex-Lightning Labs employee.

LN node devs have weekly meetings where the BOLT-specification is being discussed. You would find that the narrative that it's "Lnd's way or the highway" is just not true, if you actually did some digging.

Anyway, all LN node companies have their own fair share of Conflict of Interest. I don't see you complaining that ACINQ went proprietary with their 0-conf channel feature for their own Phoenix Wallet. A feature that all LN node implementations and wallets would benefit from. It took years before Rusty went on to do it the right way (thank you for that) and make it into the BOLT-specification. Features option_scid_alias and option_zeroconf are now supported in all big LN node implementations. A success story.

My point with this that it's not just "lnd bad, the rest good". It's childish to think like that. There is some dirt everywhere.

232 sats \ 5 replies \ @TonyGiorgio 9 Jan 2023

I think the fact that an ex employee of LL and not LL itself still shows LL's priorities here. You aren't seeing them care about Bolt12 in fact they are pretty actively against it.

Also I can tell you from experience that zeroconf integrations are dog shit and very much not a success story.

30 sats \ 4 replies \ @hampus 9 Jan 2023

I think the fact that an ex employee of LL and not LL itself still shows LL's priorities here. You aren't seeing them care about Bolt12 in fact they are pretty actively against it.

Yes. You don't decide what other people do with their time. Lightning Labs is not holding back BOLT12 as claimed in the OP. It's as far as I can tell approved for inclusion to lnd.

Also I can tell you from experience that zeroconf integrations are dog shit and very much not a success story.

Yes, you go ahead and shit other people's hard work. That's really nice of you. I'm sure you're a super developer.

The point was to show that lnd is indeed collaborating with the rest.

10 sats \ 3 replies \ @TonyGiorgio 9 Jan 2023

Yes, you go ahead and shit other people's hard work. That's really nice of you. I'm sure you're a super developer.

You call it a success story, it's not. Sorry that hit a touch spot for you.

The point was to show that lnd is indeed collaborating with the rest.

Perhaps you've never tried to open a zero conf channel with LND to another implementation. Or perhaps you've never tried to accept a zero conf channel with LND from another implementation. Maybe you should try it before calling it a success story. Sure, they collaborate, but this is a terrible example.

20 sats \ 2 replies \ @hampus 9 Jan 2023

You call it a success story, it's not. Sorry that hit a touch spot for you.

Yes, it's a success story if you stick to the topic, which is node implementation collaboration.

Perhaps you've never tried to open a zero conf channel with LND to another implementation. Or perhaps you've never tried to accept a zero conf channel with LND from another implementation. Maybe you should try it before calling it a success story. Sure, they collaborate, but this is a terrible example.

Stick to the topic.

0 sats \ 1 reply \ @TonyGiorgio 9 Jan 2023

They collaborated and failed, okay great example. Thanks for the conversations and confirmation.

20 sats \ 0 replies \ @hampus 9 Jan 2023

Bruh. What is your problem? It's one example of a collaboration out of many. It was meant to show that it's just pure FUD that lnd isn't involved in the BOLT process.

And it's not a failed collaboration. Issues are actively being addressed.

20 sats \ 0 replies \ @vnprc 9 Jan 2023 freebie

You counterexample is bunk. Carla is not a LL employee and even if she was, that repo hasn't seen any activity in months.

533 sats \ 15 replies \ @heisenberg 8 Jan 2023

Agree. And I personally think, that their market share is mainly because the fact, that LND is first/only choice in most of the "prepared solutions" like Umbrel, myNode, RaspiBlitz, Embassy, Citadel etc for plebs.

Big players are more willing to use other solutions.

843 sats \ 11 replies \ @benthecarman 8 Jan 2023

This is a symptom of the problem, the real problem being all the other implementations suck to build on top of. LND has done a really good job building tools for developers to do things on top of it very easily. Eclair is custom built for ACINQ and runs well but isn't meant to be used by everyone. CLN is basically just a hobby project by blockstream, most people I've talked to who've tried using it have had a bad experience because nothing is ever taken to completion. LDK is great but is used for building your own lightning implementation, not a drop in replacement for something like LND.

192 sats \ 0 replies \ @kristapsk 8 Jan 2023

CLN is basically just a hobby project by blockstream, most people I've talked to who've tried using it have had a bad experience because nothing is ever taken to completion.

I have completely different experience. I run both. CLN is less resource hungry, supports pruned Bitcoin nodes, is more easy extendable via plugins.

110 sats \ 1 reply \ @delta1 9 Jan 2023

It's far from a hobby project for Blockstream, but if that's a common perception it's definitely a problem.

40 sats \ 0 replies \ @benthecarman 9 Jan 2023

It's not explicitly a hobby project but it definitely feels like one, tons of things are never taken to completetion and have little documentation. They really need a PM to prioritize work for them so they can make the project more usable.

11 sats \ 7 replies \ @DarthCoin 8 Jan 2023

and blockstream don't even have a damn LN wallet... it's a shame. Why Green wallet do not have a LN support?

If wasn't for Zeus (Evan) to make something good and useful to use with CLN, nowadays, nobody will use CLN. Yes, we have Spark (really shity app) and Fully Noded ((only iOS), but those are meaningless. just saying.

180 sats \ 3 replies \ @benthecarman 8 Jan 2023

tbf lnd doesn't have a wallet either.

I'm guessing Green will get lighting support from greenlight once that is production ready.

10 sats \ 2 replies \ @DarthCoin 8 Jan 2023

yes, LL do not have their own mobile or desktop wallet. But we have many apps for LND: Blixt, Breez, Zeus, Thunderhub, RTL etc and that increase a lot of its usage.

I am sure that if we would have more apps to support CLN and easy to use, will be more users of CLN.

293 sats \ 0 replies \ @benthecarman 8 Jan 2023

Yes, this goes back to my original post, no one builds on top of CLN because lnd is so much better. CLN shouldnt waste time building an app, they should spend time making it usable so then 100 apps are built on top of it.

37 sats \ 0 replies \ @kristapsk 8 Jan 2023

Don't know about rest of the list, but RTL works with both LND and CLN.

1 sat \ 1 reply \ @delta1 9 Jan 2023

Why Green wallet do not have a LN support?

They are likely working on that feature.

0 sats \ 0 replies \ @DarthCoin 9 Jan 2023

Finally. That's a good sign.

0 sats \ 0 replies \ @ab 9 Jan 2023

It's early days, but I am working on a wallet for CLN (Clams). Right now it is designed around making payments from your phone on the go. But the plan is to highlight all of the great features that CLN provides. Bolt12, Bookkeeper accounting dashboard, Liquidity ads dashboard etc.

39 sats \ 0 replies \ @DarthCoin 8 Jan 2023

Indeed. As I explained in one of my posts: https://darthcoin.substack.com/p/recommendations-for-ln-users

9 sats \ 0 replies \ @02ecff83b0 9 Jan 2023

The sweet thing is that Core Lightning gains track and also for example Umbrel can use it well.

We either need a strong independent full open-source development or it remains a jungle right now which can also work but is far less efficient for all participants in the lightning ecosystem.

6 sats \ 0 replies \ @1fatmess 8 Jan 2023

This

339 sats \ 2 replies \ @l0k18 8 Jan 2023

btcd's bugs were not vulnerabilities. The specification and bitcoin core implementation has no sensible resource consumption limits on witness sizes. That's all it was. As a Go programmer, I am also very avid about keeping resources under control. It actually helps a lot with security as well. Resource exhaustion attacks can destroy peer to peer networks functionality.

Whoever is paying for development says what will get done. But the new features you speak of still work even when a minority of nodes support it, because they recognise each other as being able to and can make paths to run these new protocol API components.

Just like there is still a huge number of bitcoin nodes that still don't have segwit enabled.

We don't have to agree. This is a peer to peer system, ultimately. And LN can tolerate even more divergence than the bitcoin protocol because it's purely peer to peer.

You're free to fud and attack whoever you like but building is what gets you respect.

18 sats \ 0 replies \ @hampus 9 Jan 2023

The specification and bitcoin core implementation has no sensible resource consumption limits on witness sizes. That's all it was. As a Go programmer, I am also very avid about keeping resources under control. It actually helps a lot with security as well. Resource exhaustion attacks can destroy peer to peer networks functionality.

Well yeah the Taproot BIP spec explicitly removes the previous sigop and witness stack size limits, only to be bound by the blocksize instead.

Hence I would consider the bugs as vulnerabilities as they left lnd in a semi-glitchy state.

I agree with all your other points though.

0 sats \ 0 replies \ @muteness11 8 Jan 2023

all of your points are very logical ....cant disagree

258 sats \ 0 replies \ @kr 8 Jan 2023

Thanks for the write up. One clarification…

I understand their priorities are different because they are VC-funded

ACINQ is also VC-funded

As an aside, I recently spoke with Bastien at ACINQ on my podcast and he had really good things to say about the collaborative environment between the implementations today.

His view (i’m paraphrasing) was that it’s ok that all implementations aren’t exactly in lock-step with adding new features, and that they all want what is best for the Lightning Network and will eventually converge on a common set of useful features.

This video is a good one: https://www.youtube.com/watch?v=jQKe_ma0Bo0

273 sats \ 0 replies \ @runningbitcoin 8 Jan 2023

Agree that LND takes a much more buisness oriented aproach than developing along the free and open source nature of bitcoin. But from my perspective, the free market will solve that issue as the tech evolves

100 sats \ 0 replies \ @TonyGiorgio 9 Jan 2023

And to hone in on the main issue in question right now, I think this update from roasbeef really explains the situation: https://twitter.com/roasbeef/status/1612318798446743553

And I agree with it. For quite awhile people have been really dismissive of inbound fees, citing "it's not YOUR liquidity, it's your peers - you shouldn't dictate what it's priced for and you should just price your outbound accordingly" while ignoring users and some protocol devs that wanted it.

So they implement it their own way after solicitation more feedback and it doesn't hurt the network at all. All backwards compatible and optional. So what's really the issue with that? I do want inbound fees and I'm glad we get to experiment with it now. If there's a better way, let the protocol devs build it instead of talking and telling other implementations what to do.

47 sats \ 0 replies \ @cstack 8 Jan 2023

LND is a much better product than the others. They deserve their market share and the resulting ability to set Lightning's direction.

What Lightning needs is a viable competitor. Ideally, open-source and well-funded. ATTN: Jack Mallers (Strike), Jack Dorsey (Cash App), Elon Musk (Twitter), and others who are building on Lightning.....?

116 sats \ 0 replies \ @03c9da679f 8 Jan 2023 freebie

Great write up, thanks for sharing.

What can plebs and noobs (lol, me) do to help?

127 sats \ 0 replies \ @beorange 8 Jan 2023

Interesting take. Perhaps changing my node to a different implementation could be my little effort to help balancing the market.

In my case it doesn't take too much since I don't have any other tools integrated with it, but I imagine it might be harder for other people.

20 sats \ 0 replies \ @sandbeach123 8 Jan 2023

If Lightning Labs have the most used implementation, so be it, until another one proves to be better. The same can happen with Taro, if it proves reliable, most people will use it, until something else proves to be better (RGB, or other).

The day Lightning Labs (or Blockstream) becomes an IMF-WEF-OFAC controlled company, people will leave eventually.

10 sats \ 0 replies \ @iguano 9 Jan 2023

the bolt-12 issue is enough to start promoting other implementations.

10 sats \ 0 replies \ @TheVladCostea 9 Jan 2023

Use RaspiBlitz with c-lightning on your home node.

10 sats \ 1 reply \ @BlokchainB 8 Jan 2023

I think we are still super early. With this being FOSS who knows what lightning will ultimately be. Today lightning labs has first mover advantage but how do we know they won’t be obsoleted by another version that is way better. Think about IBM and how they dominated personal computers now if you ask a kid today most never even heard of an IBM thinkpad and if they did I’m almost sure they don’t want one.

120 sats \ 0 replies \ @jk_14 8 Jan 2023

Think about MS Windows and how they dominated personal computers and how much damage they did there... :(

10 sats \ 0 replies \ @muteness11 8 Jan 2023

Assuming what you said is true ... if its 90% market share then they dictate the rules .... we can make more noise for them the adjust/amend .... that is the only way but of course after a healthy debate within LN community

28 sats \ 2 replies \ @DarthCoin 8 Jan 2023

An image will say more than words...

https://i.postimg.cc/YC3D4pb2/vader-power-dark-side.jpg

https://darthcoin.substack.com/p/the-dark-side

0 sats \ 0 replies \ @BitcoinIsTheFuture 10 Jan 2023

Perfect!

0 sats \ 0 replies \ @PrinterGoBrrr 9 Jan 2023

This!

21 sats \ 1 reply \ @siggy47 8 Jan 2023

Interesting write up. Gave me food for thought. Your description of Bosworth's comments and demeanor reminds me of Gavin Andresen during the blocksize dispute.

0 sats \ 0 replies \ @rarepassenger 8 Jan 2023

Likewise. Going to be chewing on this for a bit...

15 sats \ 1 reply \ @moneydelics 8 Jan 2023

I wonder if that could be another (covert) reason why Saylor and Microstrategy are getting involved with Lightining 🤔

20 sats \ 0 replies \ @DarthCoin 8 Jan 2023

No. Saylor want to bring LN into Microstrategy software. They are a software company in the end. And LN is a natural way to use Bitcoin in an accounting system for a company.

I don't see any relation between LL (Lightning Labs) and Saylor (Microstrategy). Are two different aspects here.

20 sats \ 12 replies \ @om 8 Jan 2023

replace my LND node with Core Lightning

I agree with your sentiment but I won't even consider running a security-critical server written in pure C (not C++!) in 2023. Eclair or LDN, maybe.

46 sats \ 10 replies \ @kristapsk 8 Jan 2023

pure C (not C++!)

Linux kernel is written in pure C. Nginx is written in pure C. You don't use these?

CLN uses multiprocess architecture, so crash in one component does not bring whole server down, it just restarts crashed process. For example, separate process is run for each opened Lightning channel. From my experience, it's pretty stable, no much issues.

110 sats \ 2 replies \ @l0k18 9 Jan 2023

Git is written in C also. But all three of these are very old and very mature. By definition any LN implementation can't be more than 5 years old. C is just an ancient, literally 40 year old language.

Part of the reason why LND is so much further ahead is because, Go, having been designed by the guys who also created C (Ken Thompson, and Pike did some of the documentation on it, in addition to UNIX), have designed the language to be easy to scale, secure by default, and simple to learn, from literally 40 years of experience... including with C++, the epic compilation times being the main prompt that started the Go project.

Anything written in Go is almost inevitably going to be more advanced than anything written in any other language in relation to the amount of time it has been in development. When you are working on Go, there is just so much less things interfering with your workflow.

It's sad that so many stupid following morons think that Rust is a better language because it's marginally faster and slightly more memory efficient than Go. Rust is as complicated as C++, and even harder to learn. Doesn't really seem like a sensible trade-off if you ask me. Still waiting for Mozilla to finish Servo. Meanwhile at the same amount of time Chrome was already in full release. Servo is still a hobby project that isn't being seriously used by many projects yet, let alone the company that spawned it (and who sponsors the language it's built in). Rust basically, in my opinion, is just C++ with an arcane memory management syntax and Go's build system anyway. Anyone who thinks Rust is better than Go simply has no real knowledge of the science of language programming. It's better than C++ in terms of usability and readability maybe, that's about it, otherwise, it's practically C++ for cool kids.

And as regards to multiprocess architecture, LND uses goroutines, which are capable of scaling up rapidly with minimal memory cost to sharp increases in workload, and they are pruned off when they stall or are no longer needed.

Truly, I cannot comprehend the logic of starting a new software project in this day and age in C.

10 sats \ 1 reply \ @om 9 Jan 2023

It's sad that so many stupid following morons think that Rust is a better language because it's marginally faster and slightly more memory efficient than Go.

marginally = 2x slightly more = 2x

Rust and Go have different goals so they aren't really comparable. If you're OK with 2x more resource usage, use Go. Not that it's a particularly well-designed language with nils everywhere and weird semi-nil interface values.

100 sats \ 0 replies \ @l0k18 9 Jan 2023

You are exaggerating. I've seen numerous comparisons and Rust gets in around the same, maybe slightly better than C++, and in around the 10-20% area.

I'll concede that Go's memory utilisation can be a bit higher, but it takes a lot less time to write that code and easily 4x easier to eliminate bugs in it.

But while this may all be true, at the same time, the response latency of Go programs runs rings around most other languages even in relatively naive implementations.

Writing high parallel throughput in languages like Rust and C++ is more easy to do, but shaving the nanoseconds is something that is just easier to do when you have coroutines. Though there can be issues with scheduling when the system is at constant high load.

For me, the lack of first class coroutines is a deal breaker. I can't imagine writing programs without goroutines and channels. Not only does it enable far lower latency response and fast scaling for intermittent loads, it makes it really easy to write network programs where you start with a channel based simulation and get everything ironed out before it actually touches a network interface.

0 sats \ 6 replies \ @om 8 Jan 2023

There's no serious alternative to Linux yet. I hope Rust will grow inside the Linux kernel until there's no C left anymore.

I don't use nginx.

Crashes are one thing but all the money stolen is another. Stability is not really enough.

0 sats \ 5 replies \ @kristapsk 8 Jan 2023

Memory stolen? You mean memory leaks? They happen with golang too. Garbage collectors are never perfect. By default CLN is less resource hungry than LND, eats less memory.

20 sats \ 4 replies \ @om 8 Jan 2023

I wrote "money stolen". You know, an attack leads to buffer overflow because every C project uses a different string library (CLN's is at ccan/ccan/tal/str/str.c) and if there's a bug in it, an attacker can replace the return address and cause an arbitrary code execution.

By default CLN is less resource hungry than LND, eats less memory.

Of course. Go's GC doubles the memory. A program asks for 1 GB, Go runtime takes 2 GB. That's normal for multithreaded GCs.

0 sats \ 3 replies \ @kristapsk 8 Jan 2023

Sorry, misread you.

These libs are well tested, small chance to have bugs there, I would bet on bugs at other code. I mean, look at, for example, libc string.h, which I have reimplemented from scratch long time ago - it's simple, hard to introduce bugs there, that's why you use unit tests nowadays. More likely that bugs will be at other places. And buffer overflows aren't the only way how to introduce bugs and get money stolen.

Using Go or Rust has benefits, but it doesn't gurantee bug free code. Actual programmers, who wrote code, are more important.

So, IMO refusing to run software just because language it is written in is stupid. Although I personally am always more careful with JavaScript (node.js) stuff.

Also - fuel injection, ABS, traction control and other low level stuff in almost every car is most likely controlled by software written in C or C++. You will not drive cars because of that?

0 sats \ 2 replies \ @om 8 Jan 2023

that's why you use unit tests nowadays

They don't necessarily protect you against an attack.

More likely that bugs will be at other places.

Buffer overflows IIRC are a majority of vulnerabilities. Can't find the stats right now.

And buffer overflows aren't the only way how to introduce bugs and get money stolen.

Definitely.

You will not drive cars because of that?

If all of this is exposed to the internet then yes, maybe I won't.

0 sats \ 1 reply \ @kristapsk 8 Jan 2023

You will not drive cars because of that?

If all of this is exposed to the internet then yes, maybe I won't.

Buffer overflows with terrible consequences can be caused by any unexpected input data if code doesn't handle that, even without being connected to Internet or bad actor feeding in this data with intent.

P.S. Buffer overflow problem could have been solved by segmented memory architecture of x86 protected mode (put every data structure in different memory segment with specified size, no overflows possible, CPU handles that), unfortunatelly, that didn't get widespread use, because wasn't portable to different CPU architectures and eventually got dropped from x86_64.

view replies

0 sats \ 0 replies \ @ek 8 Jan 2023

deleted by author

0 sats \ 0 replies \ @HODLR 14 Oct

another post for ~lightning

0 sats \ 0 replies \ @0330830bf9 11 Jan 2023

Bolt12 is an attack on the network, and naming an implementation "Core" is blatant affinity scamming.

Be thankful there's resistance to the deep state Blockstream psyops.

0 sats \ 0 replies \ @PrinterGoBrrr 10 Jan 2023

There is certainly some degree of controversy and debate within the community about the best way to move forward with the development of the Lightning Network. Some have criticized Lightning Labs for prioritizing certain features or changes over others, or for making decisions that they believe could be harmful to the long-term health of the network.

While I agree on some topics, I think one should be careful throwing out accusations. No one forces us to run LND, and we could all migrate to CLN or another implementation fairly easily. So in essence, Lightning Labs is "just" a service provider with a major market share, for now.

Let's keep this civil, we don't want a blocksize war on the Lightning Network, or at least, I don't.

0 sats \ 0 replies \ @shyfire 9 Jan 2023

"CoreLightning has introduced liquidity-ads."

Was there a specification for this?

0 sats \ 0 replies \ @husseinb 8 Jan 2023

Great post, thanks for sharing your views this is very insightful.

0 sats \ 0 replies \ @gohan 10 Jan 2023 freebie

Try to see the big picture.. in the end God Almighty will destroy the banksters and any form of forbidden fraud (gambling, casinos, leverages of interest/speculation) and the clean Shariah Law conform Gold (bit?) Coin will prevail and remain. And when Isa, Jesus peace be upon him returns, He will destroy the unholy Cross and kill-prohibit the Swine. Everything between is just chess play of humans and devils..