Zcoin implementation bug enabled attacker to create over 500K Zcoins • Hacker News Board

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

#201

Post by aij » Tue, Mar 07, 2017, 5:07 PM UTC

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++

> Hello world in Rust is still 2.5MB if you statically compile all the libraries in

Still? Since when? Last I checked it was 661kB for Rust vs 829kB for C, and that was quite a while ago.

http://stackoverflow.com/a/29461455/2343847

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

#202

Post by pacaro » Tue, Mar 07, 2017, 5:22 PM UTC

yoklov wrote: post #185

pacaro wrote: post #172

Earlier quoted context omitted.

Yup. I'm a big fan of -Wall -Wextra -Werror If these options are set before you write any code, then these problems don't arise.

Worth noting you should probably disable -Werror for distribution if you expect users to compile your code. They aren't going to fix your error for you and you can't know what warnings will be added to future compilers, nor what previous compiler versions marked as errors. Among many other people saying the same thing see [0] if you don't trust me. Also IMO you often want to explicitly disable a few of those from -Wa…

Absolutely agree.

As you get further into a project you tend to need subtler tools. But for the rough work when starting out, my preference is to be stricter, which can be relaxed as necessary, rather than starting out lax and reaching a point where tightening becomes Sisyphean.

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

#203

Post by tyingq » Tue, Mar 07, 2017, 5:27 PM UTC

steveklabnik wrote: post #197

tyingq wrote: post #182

Earlier quoted context omitted.

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.

Ah...so this works:

  fn main() {
      let mut x = false;
      println!("{}", x);
      if {x=true;x} {
          println!("{}", x);
      }
  }

But stands out as pretty obvious. Not something you might easily sneak into a codebase.

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

#204

Post by steveklabnik » Tue, Mar 07, 2017, 5:51 PM UTC

tyingq wrote: post #203

steveklabnik wrote: post #197

Earlier quoted context omitted.

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

Ah...so this works: fn main() { let mut x = false; println!("{}", x); if {x=true;x} { println!("{}", x); } } But stands out as pretty obvious. Not something you might easily sneak into a codebase.

Sneaky! Yeah, no way this should get past code review, and not even easy to accidentally type.

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

#205

Post by daira » Tue, Mar 07, 2017, 6:50 PM UTC

pacaro wrote: post #172

Sanddancer wrote: post #135

Earlier quoted context omitted.

Yep. I'd add that if it's a warning you're absolutely certain of, use the warning control pragmas to suppress them, and document why the warning's suppressed. Keep the compiler output clean so you can see where you need to examine.

Yup. I'm a big fan of -Wall -Wextra -Werror If these options are set before you write any code, then these problems don't arise.

Zcash, for example, is built with `-Werror` (edit: not `-Wall`, but we're working on that). So this is absolutely feasible on a Bitcoin-derived codebase.

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

#206

Post by daira » Tue, Mar 07, 2017, 6:59 PM UTC

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…

This bug had nothing to do with Zcash. Please correct your comment to say Zcoin, if that's what you meant.

In any case, Zcash is also derived from Bitcoin and builds with `-Werror` (edit: not `-Wall`, but we're working on that). That kind of minimal static analysis is certainly not sufficient to catch the majority of bugs, though.

C++ is not memory safe in any meaningful sense. There have been efforts to define a memory-safe subset, but typical large codebases, including Bitcoin, do not come close to falling within that subset.

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

#207

Post by abrkn » Tue, Mar 07, 2017, 7:16 PM UTC

I spent quite a bit of time and effort on Zcoin during the launch, including setting up the first block explorer and mining with hundreds of EC2 instances to the point where I possessed more than 30% of the money supply.

It was a disaster. Some founders started selling their Zcoin as soon as it was listed on an exchange. The mining algorithm was changed several times.

It's a shame. Zerocoin, the underlying technology, is interesting.

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

#208

Post by phkahler » Tue, Mar 07, 2017, 7:40 PM UTC

gnode wrote: post #157

phkahler wrote: post #152

Earlier quoted context omitted.

The problem isn't in the implementation, it's a problem with Zcoin itself. One should not be able to create Zcoin via software whether that's a bug or deliberate.

How do you propose one creates Zcoin then?

Sorry, that wasn't clear. With bitcoin you could create it at will, but it requires doing a certain (constantly increasing) amount of computational work. Work that can be verified. There is no way for a bug to accidentally create a bunch of bitcoin, and no way for anyone to deliberately create any without doing the work.

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

#209

Post by WalterBright » Tue, Mar 07, 2017, 7:58 PM UTC

dagw wrote: post #117

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.

It should be an error, not a warning (default or not). In C++ you can overload '==' to do anything you want, including things that have side effects[0]. Without deeper introspection into the code, it's tricky to check if it's an error or not. [0] PS. Never do this!

Overloading means calling a function, and is treated like calling a function.

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

#210

Post by WalterBright » Tue, Mar 07, 2017, 8:00 PM UTC

Sanddancer wrote: post #148

maccard wrote: post #116

Earlier quoted context omitted.

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.

That's what volatile reads are for - they indicate a side effect.