See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

A long read. Someone has stolen $31M of Ether.

Interesting quote near the end of the article:

In blockchain, code is intrinsically unrevertible. Once you deploy a bad smart contract, anyone is free to attack it as long and hard as they can, and there’s no way to take it back if they get to it first. Unless you build intelligent security mechanisms into your contracts, if there’s a bug or successful attack, there’s no way to shut off your servers and fix the mistake. Being on Ethereum by definition means everyone owns your server.
A common saying in cybersecurity is “attack is always easier than defense.” Blockchain sharply multiplies this imbalance. It’s far easier to attack because you have access to the code of every contract, know how much money is in it, and can take as long as you want to try to attack it. And once your attack is successful, you can potentially steal all of the money in the contract.
Imagine that you were deploying software for vending machines. But instead of a bug allowing you to simply steal candy from one machine, the bug allowed you to simultaneously steal candy from every machine in the world that employed this software. Yeah, that’s how blockchain works.

But can a digital wallets/crypto currency ever be secure  ?

Nick

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
> See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce
>
> [...]

I don't think the problem was with the blockchain here. It is usually a bad idea to have turing-complete scripts over blockchains. From what I've seen the bug was that there was issued a library call based on a user-provided string. That could have never happened if they would have used D with @safe

On 8/4/2017 1:33 AM, RazvanN wrote:
> That could have never happened if they would have used D with @safe

That's mostly true, but not absolutely true.

1. There can be bugs in D's @safe checking and inference.

2. Function interfaces (such as in C interface files) are labeled @safe or not, and the D compiler has no way to check. Hence, functions can (and have been) mislabeled.

On the other hand, @safe does greatly reduce the attack surface. And as I've prognosticated before, the utter lack of machine checkable memory safety in C will herald the end of its use in anything connected to the internet.

On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote:
> On 8/4/2017 1:33 AM, RazvanN wrote:
>> That could have never happened if they would have used D with @safe
>
> That's mostly true, but not absolutely true.
>
> 1. There can be bugs in D's @safe checking and inference.
>
> 2. Function interfaces (such as in C interface files) are labeled @safe or not, and the D compiler has no way to check. Hence, functions can (and have been) mislabeled.
>
> On the other hand, @safe does greatly reduce the attack surface. And as I've prognosticated before, the utter lack of machine checkable memory safety in C will herald the end of its use in anything connected to the internet.

So, you agree that @safe cannot solve the problem because of C function interfaces and 'lack of machine checkable memory safety in C'. In this case, why does @safe relies on static analysis in CT and type inference when memory safety is determined by the 'C memory sate' at RT? Either @safe is wrongly presented (it is not memory safety tool, but something else) or (if the intention was to provide memory safety tool) it is a flawed feature.

Of course, memory safety is impossible in C. In my opinion, D's @safe is wrongly marketed as a fully safety tool (look at a user above). This is dangerous, because leads to unfounded assumptions and later disappointment.

By the way, I see that DIP 100 followed the same way - impose static type restrictions in CT to prevent memory errors. I believe, due to growing language complexity any combination of resctrictions can have loopholes. Back in 2013 I was collecting type system holes and posted them in Bugzilla after your request. It appears, that scope has its own loopholes too [1].

[1] https://issues.dlang.org/show_bug.cgi?id=17718

On Friday, 4 August 2017 at 08:33:42 UTC, RazvanN wrote:
> On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
>> See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce
>>
>> [...]
>
> I don't think the problem was with the blockchain here. It is usually a bad idea to have turing-complete scripts over blockchains. From what I've seen the bug was that there was issued a library call based on a user-provided string. That could have never happened if they would have used D with @safe


D's OpDispatch is very similar to what caused this bug ;)

struct Library
{
  void doSomethingUseful(){}
  void doSomethingNice(){}
  void resetSecurity(){}
}

struct BuggyContract
{
  private void customizedBehaviour(){}

  void opDispatch(string f)()
  {
    if(f == "doSomethingUseful")
    {
      customizedBehaviour();
    }
    else
    {
      mixin("Library.init." ~ f ~ "();";
    }
  }
}

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
> See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce
>
> But can a digital wallets/crypto currency ever be secure  ?
>

Nope... as long as humans continue to build house of cards on quicksand this sort of stuff will always happen. You do realize it's all fake nonsense? If the only sort of currency that existed was what you could immediately do with your own body, then it would be impossible to ever steal anything(except for slavery, which is essentially still fake).

Basically this is how the story goes: Someone comes up with some scheme to gather resources from others. The scheme is complex and designed in such a way that only those that have created the scheme or invested enough time to understand the scheme benefit from all those that don't but were to stupid not to buy in to the scheme.

Eventually those at the top win. It's called a pyramid scheme and it exists in all forms of currency, employment, governments, even in most relationships, etc.

Only when all participants equally share complete responsibility can the scheme be fair... but that never happens, too much to gain when it becomes unbalanced... and the more unbalanced it becomes the more those that unbalance it get.

I wouldn't doubt that most of these people who create these currencies are the ones that ultimately are behind these thefts. After all, they are the ones that know most about it and why else would they spend their time developing it? For the benefit of human kind? Yeah right! What a joke!

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
> See - https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce
>
> A long read. Someone has stolen $31M of Ether.
>

To give an idea of how bad it is:

https://news.ycombinator.com/item?id=14691212

Anyone writing smart contracts on ETH right now is crazy.

On 8/4/2017 2:26 AM, Maksim Fomin wrote:
> So, you agree that @safe cannot solve the problem because of C function interfaces and 'lack of machine checkable memory safety in C'. In this case, why does @safe relies on static analysis in CT and type inference when memory safety is determined by the 'C memory sate' at RT? Either @safe is wrongly presented (it is not memory safety tool, but something else) or (if the intention was to provide memory safety tool) it is a flawed feature.

Every memory safe language that talks to C code (Rust, Java, etc.) has this issue. Once you step outside the language, guarantees cannot be made. It's not reasonable to assume otherwise.

> It appears, that scope has its own loopholes too [1].
> [1] https://issues.dlang.org/show_bug.cgi?id=17718

All languages have bugs in their implementations. What do you suggest we do about that?