5 ms·

This is a very pro-Ether take on what happened, but ultimately it comes to the right conclusion: > The problem is that his programming toolchain allowed him to

This is a very pro-Ether take on what happened, but ultimately it comes to the right conclusion: > The problem is that his programming toolchain allowed him to make these mistakes. Damn straight. The problem is that the model of 'public by default, opt in for security' is fundamentally daft in this context. There's quite a good read on that particular topic here too http://hackingdistributed.com/2017/07/20/parity-wallet-not-alone/ http://hackingdistributed.com/2017/07/20/parity-wallet-not-a.... ...but hey, if this ends up making Ethereum better, more secure and more robust as a result, then that's a good thing; it probably does need a different better language to express code in. Just remember... > certainly you should not store any money in a hot wallet that you’re not comfortable losing.

jumbosuno 9y ago
will Tezos help with Ocaml to make better contracts? I think that is the whole point of Tezos!
pdkl95 9y ago
> the model of 'public by default, opt in for security' is fundamentally daft in this context. It's daft in most contexts, and is one of the largest sources of security problems. If your design requires enumerating badness[1], you're doing it wrong. > from: http://hackingdistributed.com/2017/07/20/parity-wallet-not-alone/ http://hackingdistributed.com/2017/07/20/parity-wallet-not-a... >> Just about every ICO, trust and company used the Parity multisig wallet, and that code was considered well-tested. -sigh- This is, unfortunately, a common problem. "It worked ok the last N times" and "It passed a lot of tests" do not mean it's bug-free and safe to use. Richard Feynman was right during the Challenger investigation when he called this a childish attitude. (He was also right in not wanting to assign blame, instead asking "How do we educate the child?"[2]) [1] http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [2] https://www.youtube.com/watch?v=4kpDg7MjHps#t=150 https://www.youtube.com/watch?v=4kpDg7MjHps#t=150
SingletonIface 9y ago
The page you linked mentioned "SafeMath". Is this that? https://github.com/nemequ/portable-snippets/blob/master/safe-math/README.md https://github.com/nemequ/portable-snippets/blob/master/safe...
mannykannot 9y ago
>This is a very pro-Ether take on what happened, but ultimately it comes to the right conclusion: >> The problem is that his programming toolchain allowed him to make these mistakes. This is not the right conclusion; it is too shallow. It suggests that the risks of smart contracts can be fixed with some changes to the programming toolchain, but no-one has ever made one that only produces secure code, and I think I can safely call that notion a pipe-dream. How, then, do we write code with the level of security needed by smart contracts, and in the volume needed for smart contracts to be useful, if they are to be publicly accessible like Ethereum? The fact is, this has never been done before at that volume, and we do not know how to do it. > Just remember... >> certainly you should not store any money in a hot wallet that you’re not comfortable losing. But what does it take to be comfortable? Unless you are just going to take someone else's word for it, you would have to examine all the code, including the libraries and the EVM itself, and be competent enough in security to be comfortable that you had not overlooked ay risks. But the real problem is that this does not just apply to hot wallets, it applies to anything that puts your Ethereum at risk. So, in practice, 'being comfortable' means trusting a bunch of people you probably do not know well, and with no recourse if that trust turned out to be overly optimistic.
- sillysaurus3 9y ago
  Yes, but this reductive view isn't useful. It's happening, whether we know how to do it or not. The important question is how to proceed.
  - mannykannot 9y ago
    Proceeding by ignoring the inherent difficulties is certainly an option... In fact, that is how we got to the current situation.
    - sillysaurus3 9y ago
      The thing is, everyone knows it's difficult. It's not new information. The people who proceed anyway stand to benefit handsomely if they don't screw it up. So the game is simply: don't screw up. It's hard, to be sure. But to say it's impossible is to overstate the issue. And even if it is impossible, it doesn't mean it will end in disaster 100% of the time.
mpeg 9y ago
But the function people were exploiting needed to be public, I don't see how internal by default would have made any difference. The real issue here is that the class constructor called a function instead of containing all code within itself. It's a fundamental misunderstanding of how the EVM works and how Solidity compiles to it. I've read the code and it's hard to convey the level of incompetence that went into having a dynamic call from the Wallet constructor to the initWallet function; but it's very, very high.
- JeremyBanks 9y ago
  It's below the level of incompetence required to design and deploy a language for this specific purpose that makes such misuse so simple, and apparently also below the level of incompetence of the Ethereum community who allowed $100M to be protected by it.
- deleted 9y ago
  [deleted]

jumbosuno 9y ago

will Tezos help with Ocaml to make better contracts? I think that is the whole point of Tezos!

pdkl95 9y ago

> the model of 'public by default, opt in for security' is fundamentally daft in this context. It's daft in most contexts, and is one of the largest sources of security problems. If your design requires enumerating badness[1], you're doing it wrong. > from: http://hackingdistributed.com/2017/07/20/parity-wallet-not-alone/ http://hackingdistributed.com/2017/07/20/parity-wallet-not-a... >> Just about every ICO, trust and company used the Parity multisig wallet, and that code was considered well-tested. -sigh- This is, unfortunately, a common problem. "It worked ok the last N times" and "It passed a lot of tests" do not mean it's bug-free and safe to use. Richard Feynman was right during the Challenger investigation when he called this a childish attitude. (He was also right in not wanting to assign blame, instead asking "How do we educate the child?"[2]) [1] http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [2] https://www.youtube.com/watch?v=4kpDg7MjHps#t=150 https://www.youtube.com/watch?v=4kpDg7MjHps#t=150

SingletonIface 9y ago

The page you linked mentioned "SafeMath". Is this that? https://github.com/nemequ/portable-snippets/blob/master/safe-math/README.md https://github.com/nemequ/portable-snippets/blob/master/safe...

mannykannot 9y ago

>This is a very pro-Ether take on what happened, but ultimately it comes to the right conclusion: >> The problem is that his programming toolchain allowed him to make these mistakes. This is not the right conclusion; it is too shallow. It suggests that the risks of smart contracts can be fixed with some changes to the programming toolchain, but no-one has ever made one that only produces secure code, and I think I can safely call that notion a pipe-dream. How, then, do we write code with the level of security needed by smart contracts, and in the volume needed for smart contracts to be useful, if they are to be publicly accessible like Ethereum? The fact is, this has never been done before at that volume, and we do not know how to do it. > Just remember... >> certainly you should not store any money in a hot wallet that you’re not comfortable losing. But what does it take to be comfortable? Unless you are just going to take someone else's word for it, you would have to examine all the code, including the libraries and the EVM itself, and be competent enough in security to be comfortable that you had not overlooked ay risks. But the real problem is that this does not just apply to hot wallets, it applies to anything that puts your Ethereum at risk. So, in practice, 'being comfortable' means trusting a bunch of people you probably do not know well, and with no recourse if that trust turned out to be overly optimistic.

sillysaurus3 9y ago
Yes, but this reductive view isn't useful. It's happening, whether we know how to do it or not. The important question is how to proceed.
- mannykannot 9y ago
  Proceeding by ignoring the inherent difficulties is certainly an option... In fact, that is how we got to the current situation.
  - sillysaurus3 9y ago
    The thing is, everyone knows it's difficult. It's not new information. The people who proceed anyway stand to benefit handsomely if they don't screw it up. So the game is simply: don't screw up. It's hard, to be sure. But to say it's impossible is to overstate the issue. And even if it is impossible, it doesn't mean it will end in disaster 100% of the time.

mpeg 9y ago

But the function people were exploiting needed to be public, I don't see how internal by default would have made any difference. The real issue here is that the class constructor called a function instead of containing all code within itself. It's a fundamental misunderstanding of how the EVM works and how Solidity compiles to it. I've read the code and it's hard to convey the level of incompetence that went into having a dynamic call from the Wallet constructor to the initWallet function; but it's very, very high.

JeremyBanks 9y ago
It's below the level of incompetence required to design and deploy a language for this specific purpose that makes such misuse so simple, and apparently also below the level of incompetence of the Ethereum community who allowed $100M to be protected by it.
deleted 9y ago
[deleted]