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

Zcoin implementation bug enabled attacker to create over 500K Zcoins

makebitcoingreatagain.wordpress.com

Post reply on HN
Print view View original

141–150 of 223 posts

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#141

Post by lmm »

caf wrote: post #132
lmm wrote: post #102

Earlier quoted context omitted.

That is absolutely a bug in C++'s ergonomics. Languages that use pascal-style := for assignment would not have this problem. Languages that don't have the surprising value behaviour of = would not have this problem. Hell, even as crude a language as Java would not have this problem because it doesn't allow an integer to implicitly decay to a boolean. Building with warnings on would also have caught it, but the fact t…

This doesn't have anything to do with the value behaviour of =. The statement in question was intended to be a simple assignment, throwing away the value of the = operator and only using its side-effect. Instead an equality operator was used, which produced no side-effect. So if you want to blame anything, blame the concept of expression statements, I guess?

Ah, the error was the other way around.

The idea that you form a value by creating an uninitialized one and then filling in its fields is dumb. (I suspect the field value wasn't even 0 as such but rather undefined, and the implementation happened to make it 0?). Better languages have you initialize the value directly and you can't access it until it's fully initialized. C/C++ are just really bad at expressing nontrivial values, even value literals.

(Discarding a value ought to be an error too, though that's more cumbersome to work with)

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#142

Post by _pmf_ »

yjgyhj wrote: post #71

The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…

HN's law: all problems with C can be solved by writing a sufficiently high-brow post containing snide observations only a sophomore is smart enough to come up with..

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#143

Post by matt4077 »

repomies6991 wrote: post #74
seibelj wrote: post #2

> If the attacker managed to liquidate their Zcoins at an average price of $1.25, they may have netted themselves upto USD 750,000. If you are a skilled programmer / security expert / mathematician, crypto currency exploit creation seems to be an extremely lucrative hobby.

Well, crypto/bitcoin businesses in general tend to be quite lucrative. However lots of risks as well. For a security researcher there are no downside risks as much.

> crypto/bitcoin businesses in general tend to be quite lucrative.

That's called a pyramid, or ponzi scheme.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#144

Post by posterboy »

zuzun wrote: post #100
yjgyhj wrote: post #71

The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…

You are looking at a 1k LOC function in a 7k LOC file with a bug that can be easily spotted by -Wall and you think it's the fault of the programming language? The only thing irresponsible is putting your hard-earned money into the 100th Bitcoin fork maintained by some guy with an Anime avatar. Once you stop trusting the developers it essentially becomes an underhanded ... contest and no language wins.

don't forget to mention the alegations against the one of the creators/evangelists

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#145

Post by spacemanmatt »

lmm wrote: post #102
easytiger wrote: post #101

Earlier quoted context omitted.

This bug had nothing to do with c++ and its ergonomics, let alone it's safety. > Unfortunately when populating the denomination member variable, an equality operator was used instead of assignment, resulting in the denomination always being zero, as set in the class constructor. So = Vs ==

That is absolutely a bug in C++'s ergonomics. Languages that use pascal-style := for assignment would not have this problem. Languages that don't have the surprising value behaviour of = would not have this problem. Hell, even as crude a language as Java would not have this problem because it doesn't allow an integer to implicitly decay to a boolean. Building with warnings on would also have caught it, but the fact t…

I was using C++ in 1994. I am fully amused today to hear 'ergonomics' attributed to the language, even with the qualifier 'bad.' I'll spare you the rest of this "back in my day" post. I just can't fault the language for a project creator not including -Wall in the Makefile or whatever they used to build.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#146

Post by Sanddancer »

yjgyhj wrote: post #129
Sanddancer wrote: post #95

Earlier quoted context omitted.

Because pretty much any language that's been touted as a replacement has problems which need solved before they'd really be viable. They're either single vendor with no independent standardization, like Rust or D, or have lower performance like go, or both. Once both problems are fixed, it'll be a lot easier to start looking at alternatives. Until then, there's not a language that settles into a lot of the niches C a…

Haskell has not even close as many libraries, sure. I don't know ZCoin but I have implemented a (simple) Bitcoin wallet. For that you need to have a good crypto library, but otherwise it's not magic. Mining as well. I think the lesser amount of libraries and lacking the chance of fine-tuning performance (but also your risk of screwing up your performance badly) is a very low price for the provably impossibility to ha…

Code like this, there were just as many, if not more, logic errors that wouldn't be caught as there were mechanical problems that would have been caught with a more diligent compiler. There's just not the discipline there for good code, period. Too many corners cut, too much code commented out, etc.

I think with the types of errors you mentioned, that part of it definitely is ecosystem. Look at OpenBSD, for example. They've built things like a safer malloc and fairly extensive patches to gcc that have caught a lot of errors and bugs. I think C/C++ can definitely get safer without changing that much, the ecosystem just needs to get a bit angrier about warnings, etc.

Standardization, and multiple implementations, means you can have multiple sets of compiler eyeballs looking over things. The zcoin bug, for example, emits a warning with the default settings of clang, but doesn't emit a peep with the default settings of gcc. For someone working with a lot of embedded code, it also means that there's a better chance that there's an implementation of the language ready to go when you need to move to a different platform.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#147

Post by spacemanmatt »

yjgyhj wrote: post #140
caf wrote: post #132

Earlier quoted context omitted.

This doesn't have anything to do with the value behaviour of =. The statement in question was intended to be a simple assignment, throwing away the value of the = operator and only using its side-effect. Instead an equality operator was used, which produced no side-effect. So if you want to blame anything, blame the concept of expression statements, I guess?

You can rightfully blame having state setting be part of your language. It is easier to program without state than with it, just like it's easier to juggle 2 balls than 3. Without state (or with the absolutely minimum of it) you can not make mistakes with it. Also, if your state-setting operator is super similar to your equality-checking operator, you can fall into this trap (like the devs in question did). Programmi…

Picking up Clojure and learning to be extremely judicious about the use of persistent state reduced my bug output rate dramatically.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#148

Post by Sanddancer »

maccard wrote: post #116
WalterBright wrote: post #42

The error is here: https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489... and the line of code: zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE; In other words, a statement with no effect. In D, such a line gives an error, not a warning: Error: == has no effect in expression You can force the statement to be accepted by casting it to void. It's really past time for languages to not accept such code any…

I'm not advocating writing any code like this, but you can have an overloaded == operator that _does_ have side effects, e.g. [0] [0] https://ideone.com/eJgiN9

It gets more fun when you're dealing with things like memory mapped I/O, where reading from a register is a destructive action, so even a non-overloaded == can cause side effects.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#149

Post by spacemanmatt »

_pmf_ wrote: post #142
yjgyhj wrote: post #71

The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…

HN's law: all problems with C can be solved by writing a sufficiently high-brow post containing snide observations only a sophomore is smart enough to come up with..

Au contraire. I've had a long career in the field (various domains, I'm always the "code guy") and it's actually useful to me to hear people besides myself expressing the level of surprise/frustration/bemusement they experience. It keeps the trade from being utterly dry.

Re: Zcoin implementation bug enabled attacker to create over 500K Zcoins

#150

Post by spacemanmatt »

jacquesm wrote: post #63
WalterBright wrote: post #59

Earlier quoted context omitted.

It should be an error, not a warning (default or not). There are a number of things like this that should just not be accepted anymore. Here's another one: if (condition); dothis(); No compiler should accept that, regardless of switch settings.

Fully agreed. There is absolutely no way that is something a programmer ever intended. In fact I think that just if (condition); Should already be enough to trigger the error. (Any 'if' statement without a body).

There could be an important side-effect in condition. Isn't persistent state fun!?
Post reply on HN