pull down to refresh
20 sats \ 12 replies \ @om 8 Jan 2023 \ on: Is LND (Lightning Labs) ruining the Lighting Network? bitcoin
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.
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.
reply
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.
reply
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.
reply
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.
reply
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.
reply
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.
reply
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.
reply
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?
reply
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.
reply
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.
reply
It can be, yes, but mostly in the sense that one can win a lottery. It is bad actors that you should beware of.
deleted by author
reply