atomic operations are not a cybersecurity skill in particular, it's a generic programming concept that more often guards against bugs rather than attackers. Although it is the case that attackers often exploit bugs, it's more likely that you are just learning to program and don't know the difference between both.

Congrats on making money though.

▲

ojr a day ago | parent [-]

Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc.

When you apply these programming concepts like atomic operations to something that control moneys it becomes security engineering.

Atomicity is literally the foundation of preventing double spending in a financial system. If people can spend bitcoin twice the price crashes to $0. Understanding atomicity is very important for cybersecurity/integrity of the system.

With more programming experience you’ll understand the mapping of studying crypto smart contract vulnerabilities and applying lessons to a non-blockchain database.

Programmers like you make me never feel threaten that my apps would be cloned, too many gaps in knowledge of system design.

▲

TZubiri 10 hours ago | parent [-]

>Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc.

With the exception of rate limiting, those are indeed security techniques.

The generic programming concepts, like Atomicity and rate limiting are generic because, although maybe relevant to security, they would exist even without malicious actors. Atomicity for example is used on disk and database writes to avoid ilegal states in the case of power outages or crashes. Rate limiting on the other hand would still exist without malicious actors, to distribute limited resources when demand exceeds supply. And it often is used in the context of paid apis with different pricings based on different limits.

So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors.

>With more programming experience you’ll understand the mapping of studying crypto smart contract vulnerabilities and applying lessons to a non-blockchain database.

If I'm not mistaken you started learning about programming and security very recently (which is why you can't distinguish between the two) and mostly through chatgpt? Might pay off to be less cocky, or maybe it's a good strategy so that veterans correct you, either way, all the best.

	▲	ojr 5 hours ago \| parent [-]
		> So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors. Guess what both fall under umbrella of cybersecurity. Please consult with your favorite LLM to break it down to you. I can't continue having a conversation with a beginner posturing as a security veteran, who thinks rate limiting and having atomic operations in things that involve money is not cybersecurity. blockchain smart contracts I wrote 8 years ago: https://github.com/Slidebits/ethereum-smart-contracts iOS app, that "good faith" hackers try to constantly abuse through what you call "random conditions": https://apps.apple.com/us/app/slidebits-ai-playground/id1138... Maybe you can share some of things that form your opinion?