Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In-Memory C++ Leap in Blockchain Analysis

caudena.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: In-Memory C++ Leap in Blockchain Analysis

#61

Post by FpUser »

wat10000 wrote: post #24
kanbankaren wrote: post #20

Earlier quoted context omitted.

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

What a terrifying statement. Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubri…

>"What a terrifying statement."

The statement may not be correct but calling it terrifying is way melodramatic.

Re: In-Memory C++ Leap in Blockchain Analysis

#62

Post by wat10000 »

FpUser wrote: post #61
wat10000 wrote: post #24

Earlier quoted context omitted.

What a terrifying statement. Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubri…

>"What a terrifying statement." The statement may not be correct but calling it terrifying is way melodramatic.

I don’t think so. The fact that someone with extensive experience thinks modern C++ is safe because it has semaphores and mutexes and smart pointers is legitimately scary. It’s not merely wrong, it reflects a fundamental misunderstanding of what the problem even is. It’s like an engineer designing airliners saying that they can be perfectly safe without any redundant systems because they have good wheels. That should have you backing away slowly while asking which manufacturer they work for.

Re: In-Memory C++ Leap in Blockchain Analysis

#63

Post by FpUser »

wat10000 wrote: post #62
FpUser wrote: post #61

Earlier quoted context omitted.

>"What a terrifying statement." The statement may not be correct but calling it terrifying is way melodramatic.

I don’t think so. The fact that someone with extensive experience thinks modern C++ is safe because it has semaphores and mutexes and smart pointers is legitimately scary. It’s not merely wrong, it reflects a fundamental misunderstanding of what the problem even is. It’s like an engineer designing airliners saying that they can be perfectly safe without any redundant systems because they have good wheels. That should…

I think their statement amounts to something like in line of: subset of modern C++ and feature usage patterns can be reasonably safe and I am ok with it. Nothing is ever really safe of course. One should consider trade offs of quality / safety vs costs and make their own conclusion on where to lean more and where enough is enough.

Re: In-Memory C++ Leap in Blockchain Analysis

#64

Post by dboreham »

CharlesW wrote: post #29
kanbankaren wrote: post #20

Earlier quoted context omitted.

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-s…

Real Programmers use C++

Re: In-Memory C++ Leap in Blockchain Analysis

#65

Post by wat10000 »

FpUser wrote: post #63
wat10000 wrote: post #62

Earlier quoted context omitted.

I don’t think so. The fact that someone with extensive experience thinks modern C++ is safe because it has semaphores and mutexes and smart pointers is legitimately scary. It’s not merely wrong, it reflects a fundamental misunderstanding of what the problem even is. It’s like an engineer designing airliners saying that they can be perfectly safe without any redundant systems because they have good wheels. That should…

I think their statement amounts to something like in line of: subset of modern C++ and feature usage patterns can be reasonably safe and I am ok with it. Nothing is ever really safe of course. One should consider trade offs of quality / safety vs costs and make their own conclusion on where to lean more and where enough is enough.

There's an argument to be made that you can write safe C++ by using the right subset of the modern language. It might even be a decent argument. But that's not the argument that was made here. They mentioned two things that have only the most tangential connection to security and that aren't even part of C++, plus one C++ feature that solves exactly one problem.

Re: In-Memory C++ Leap in Blockchain Analysis

#66

Post by wat10000 »

kanbankaren wrote: post #52
wat10000 wrote: post #46

Earlier quoted context omitted.

Any reasonable meaning of “proper” would include not causing memory issues, so you’ve just defined away any problems. Note that this is substantially different from not having any problems. The great lesson in software security of the past few decades is that you can’t just document “proper usage,” declare all other usage to be the programmer’s fault, and achieve anything close to secure software. You must have syste…

> And when was the last time you found a bug in C-family code caused by someone who didn’t correctly use concurrency primitives because the programmer incorrectly believed that a certain piece of mutable data would only be accessed on a single thread? I’ll give you my answer: it was yesterday. You answered my question. My original argument was using concurrency primitives "properly" in C++ prevents memory issues and…

> My original argument was using concurrency primitives "properly" in C++ prevents memory issues

Yes, I know, I addressed that. It's true by definition, and a useless statement. Improper usage will happen. If improper usage results in security vulnerabilities, that means you will have security vulnerabilities.

Note that I say this as someone who makes a very good living writing C++ and has only dabbled in rust. I like C++ and it can be a good tool, but we must be clear-eyed about its downsides. "It's safe if you write correct code" is a longer way to say "it's unsafe."

Re: In-Memory C++ Leap in Blockchain Analysis

#68

Post by twoodfin »

jnkl wrote: post #45
caudena wrote: post #8

Earlier quoted context omitted.

First of all, at Caudena, we are not involved in crypto projects or investments ourselves. Our expertise lies in analyzing blockchains and providing deep technical insights into how various blockchains operate. We focus on tracking and understanding the flow of digital assets, often in support of government agencies investigating scams, fraud, and other illicit activities. That said, we absolutely believe that blockc…

Can you be a bit more specific about the practical aspects of block chain technology regarding RWA?

IANABCE but…

It’d be really great to be able to price predictions for various RWA at a fine grain: “Will IBM be >$240 next Friday at market close?” “Will George Alleline default on his mortgage for 46 Smiley Court?”

But manually creating and marketing these nanosecurities has too much overhead. Traditionally you’d bundle up a bunch of small stuff into a derivative, but that creates a complex instrument that’s hard to price—and then you get a Global Financial Crisis.

Block chains offer the potential to make these kinds of nano trades self-executing at scale.

Re: In-Memory C++ Leap in Blockchain Analysis

#69

Post by newswasboring »

seviu wrote: post #56
newswasboring wrote: post #48

Earlier quoted context omitted.

All of these are at best nice prospects and most of these are just services which are only useful if the space itself is useful. I'm sorry but I'm not convinced of utility by layers upon layers of "successful" protocols.

I wouldn’t call polymarket a nice prospect though.

I wouldn't call gambling a productive usecase though.
Post reply on HN