Live data from Hacker News

Zcoin implementation bug enabled attacker to create over 500K Zcoins

makebitcoingreatagain.wordpress.com

81–90 of 223 posts

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

#81
post #80
post #79

Earlier quoted context omitted.

Because old habits die hard. Using 'unmanaged' languages for 'performance' reasons is no longer a good reason, because the likes of C# have shown multiple times that there is no reason to choose C++ over C# if you look at performance alone (difference is neglible).

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.

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

#82
post #13
post #4

Im curious. Is this actually illegal? Is there any requirement on how valid crypto currency is created? I understand the network could implement a fix and prevent future transactions or even roll back old ones if there's enough desire, that's what democracies are about right? But was there anything illegal about creating and then trading them? A rollback would hurt the exchanges, but if they didn't already have somet…

I'm under the impression that the general philosophy of cryptocurrencies is that the code is the law. You can do anything that the code will allow you to do, because it's designed so that you can trust the system and not people. It's a small step to say that it's also not the programmers' intent that matters, but the code itself, because it's the code that matters, not people. (I'm not sure how this relates to courts…

This isn't true, given how frequently hard forks happen in crypto. This means that the code said one thing, but the community decided that it was the wrong thing and everyone moved on to the new fork.

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

#83
post #76
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…

Luckily there are some Blockchain/Crypto currency startups that do understand the value of using something like Haskell. See https://iohk.io/projects/cardano/

These pump-and-dump schemes are getting ridiculous. Implementing a cryptocurrency client in Haskell isn't enough to justify creating an entirely new currency. Whether or not the protocol itself is sound is (almost) completely orthogonal to the language in which it's implemented, and at this point there are dozens of Bitcoin clients written in many languages (including Haskell [1]), so it's extremely unlikely that Bitcoin as a whole is still at risk from unsafe language choice.

1: http://haskoin.com

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

#84
post #80
post #79

Earlier quoted context omitted.

Because old habits die hard. Using 'unmanaged' languages for 'performance' reasons is no longer a good reason, because the likes of C# have shown multiple times that there is no reason to choose C++ over C# if you look at performance alone (difference is neglible).

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).

It's worth pointing out that the majority of large C++ projects contain non-deterministic memory management (reference counting) and cache-inefficient object structures like C#.

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

#85
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…

What is even worse that those guys are not able to use C++ properly. They created function with more than 1000 lines with so many branches! It will be almost impossible to write test which tries all code paths. I do not think that changing language would help in this case with such programmers.

The bug happened in "inlined constructor" so they should check all uses of this class/struct to check if it is not copied to other places (and probably all other structs/classes).

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

#87
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…

Depends on your definition of irresponsible.

Companies exist to make money so the most responsible thing to do is make as much money as possible. If breaking the law means you will make more money then do it.

See: a x b x c = x formula from Fight Club or Uber's entire business model.

Your assumption that we don't want bugs is probably why you are asking the question. Companies don't care about bugs, they care about losing money so if the bug doesn't cost money it's not worth fixing until it costs more than the fix.

I think this is actually very short sighted but that's just how the incentives align in our current system.

I make no claim to the philosophical implications of any of this.

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

#88
post #84
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).

It's worth pointing out that the majority of large C++ projects contain non-deterministic memory management (reference counting) and cache-inefficient object structures like C#.

Absolutely. But note that if you don't have cycles, reference counting of SOME objects is faster than having a GC for everything. The RAII idiom when used in C++ helps with statically determining that some objects can be released at defined points without having to reference count them.

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

#89
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 than nonsense languages like Ocaml or Haskell.

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

#90
post #77

Earlier quoted context omitted.

That's the equivalent of a 32 branch switch statement in one line. So only 31 other cases to test for, now let's hope they did all those tests.

I'm definitely not advocating for unnecessarily complex or long conditionals on a single line or any other hard-to-grok code, but this comment reminded me of something I just learned recently! Someone on my team introduced me to property-based testing, which generates ranges of test cases that would otherwise be very repetitive to write manually. We've used http://hypothesis.works/ in a few places recently and caught…

Were you using their python version or the Java one?
Post reply on HN