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

191–200 of 223 posts

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

#191

Post by lmm »

igouy wrote: post #190
lmm wrote: post #163

Earlier quoted context omitted.

> nobody who writes C# managed to produce a benchmark yet that beats a C++ program No, but I've seen Haskell programs that were much faster than the C++ program they replaced, which is what matters in the real world. Microbenchmarks measure what happens if you have the time to polish every single line to perfection. If you have infinite developer time then C++ will be faster than most languages. But infinite develope…

Did the Haskell programs implement the same algorithm?

It implemented the same business requirements. I don't know or care what algorithm was involved (indeed I wouldn't really say there was one).

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

#192

Post by igouy »

hvidgaard wrote: post #81
iopq wrote: post #80

Earlier quoted context omitted.

The difference is not negligible: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Sure, it's silly benchmarks, so I wouldn't take the results as gospel. But the fact is, nobody who writes C# managed to produce a benchmark yet that beats a C++ program. Fast languages like Rust have managed to at least match the performance of C in some benchmarks (and even beat it in others).

Properly unmanaged code will probably always be faster than managed code. But the point still stands. Code in a managed language, identify the hot spots and inject highly performant unmanaged code there. There is no need to go full C++ for 99.999% of all projects.

Like this?

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

How should /unsafe be set with .Net CORE csproj ?

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

#193

Post by igouy »

lmm wrote: post #191
igouy wrote: post #190

Earlier quoted context omitted.

Did the Haskell programs implement the same algorithm?

It implemented the same business requirements. I don't know or care what algorithm was involved (indeed I wouldn't really say there was one).

"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" :-)

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

#194

Post by CyberDildonics »

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…

Hello world in Rust is still 2.5MB if you statically compile all the libraries in since it doesn't strip unused functions. The tools and ecosystem are nowhere near what they are for C++

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

#195

Post by igouy »

NKCSS wrote: post #92
iopq wrote: post #80

Earlier quoted context omitted.

The difference is not negligible: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Sure, it's silly benchmarks, so I wouldn't take the results as gospel. But the fact is, nobody who writes C# managed to produce a benchmark yet that beats a C++ program. Fast languages like Rust have managed to at least match the performance of C in some benchmarks (and even beat it in others).

If they were properly written, I'd accept that, but just take a look at how vastly different things these two are doing: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

Isn't that the usual explanation for why some program is faster than some other program? They do things differently.

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

#196

Post by steveklabnik »

CyberDildonics wrote: post #194
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…

Hello world in Rust is still 2.5MB if you statically compile all the libraries in since it doesn't strip unused functions. The tools and ecosystem are nowhere near what they are for C++

If this matters to you, it's not hard to get it down to something much smaller.

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

#197

Post by steveklabnik »

tyingq wrote: post #182
aethertap wrote: post #179

Earlier quoted context omitted.

Actually the type system catches that particular mistake: error[E0308]: mismatched types --> src/main.rs:5:6 | 5 | if x = 1 { | ^^^^^ expected bool, found () | = note: expected type `bool` = note: found type `()` error: aborting due to previous error error: Could not compile `playground`. To learn more, run the command again with --verbose.

Interesting. Is there any plausible way that Rust can fall into the == vs = trap?

No, as assignment always results in (), and if always requires a boolean. This is by design.

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

#198

Post by steveklabnik »

xcthulhu wrote: post #175
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…

> Why do we do this, still? Is it not irresponsible? One reason is security - if cryptography isn't done in constant time then there is the potential for timing attacks. This is why BitCoinJ ditched BouncyCastle for their own JNI wrapper around BitCoin's libsecp256k1. There is a rust client for Ethereum, called Parity - they do FFI calls to libsecp256k1. Similarly rust-crypto vendors most of its crypto in C that it c…

MaidSafe moved to Rust in 2015 https://blog.maidsafe.net/2015/07/01/the-ants-are-coming/

I gave a talk with a summary of why they switched from C++ as part of this general talk on production Rust last year: https://www.infoq.com/presentations/rust-production

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

#199

Post by aij »

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…

Writing stateful code by default in hopes that it will be faster is a premature optimization IMNSHO.

A lot of times it isn't actually any faster, and it's certainly more error prone.

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

#200

Post by aij »

robertgraham wrote: post #89
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…

It's an absurd point. ZCash was built upon the Bitcoin codebase. This inherits a lot of bad decisions. Moral purity, demanding they start over again from scratch, just isn't practical. The bug in question could have been solved had the simply compiled with minimal static analysis -- by which I mean -Wall. C/C++ is memory safe if you turn on dynamic checking. Sure, it's twice as slow as C/C++, but still tons faster th…

> C/C++ is memory safe if you turn on dynamic checking.

What's the option to turn that on? Which compilers is it in?

I know there were several fat-pointer patches to GCC back in the day, but I didn't think anything remotely similar had ever gone mainstream. There's just too much existing code that relies on undefined behavior last I checked.

Post reply on HN