4

People use this contract everyday http://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol and it's also the contract with most ethereums right now.

Also you can create a multisig account on the official Ethereum Wallet using this contract source code.

But then when I go inside the site https://etherscan.io/address/0xab7c74abc0c4d48d1bdad5dcb26153fc8780f83e#code we have all these warnings stating that low security

Warning: The compiled contract might be susceptible to ZeroFunctionSelector (very low-severity), DelegateCallReturnValue (low-severity), ECRecoverMalformedInput (medium-severity), SkipEmptyStringLiteral (low-severity), IdentityPrecompileReturnIgnored (low-severity), HighOrderByteCleanStorage (high-severity), SendFailsForZeroEther (low-severity), DynamicAllocationInfiniteLoop (low-severity), CleanBytesHigherOrderBits (medium/high-severity) Solidity compiler bugs.

How should I as a investor (and a programmer that has not fully learned Solidity) use this? Of course I have heard the Parity exploit which gave hackers freedom to just take 30 Milion USD.

My question is: Should I be worried? And what should I be careful with and pay attention to?

UPDATE:

I understand you but I can the basic solidity and I can't see any "internal" functions or "guards" which was put in action by parity after their exploit.

But here I have a more in depth analysis by the solidity remix simulator stating re-entrancy vulnerabilities: https://imgur.com/a/d3x8J

UPDATE 2:

You said higher compiler version is better well all of the contracts using that code (which I said is the one used in the Ethereum wallet) use version 0.3.2! 0.3.2! Which is from 2016!

4

The entire Ethereum ecosystem is in the beginning stages. Mistakes are to be expected, but they should of course not be tolerated if it involves large amounts of money.

There are basically two types of vulnerabilities that can allow funds to be stolen:

  1. Programmer mistakes

    For example, the re-entrancy vulnerability used to be commonplace. Most DApp developers today are aware of this and will not make that mistake.

    Nowadays most mistakes are specific to the logic of a certain application. The only way you can be sure there aren't any is by formal verification, extensive code review and/or the test of time & money.

  2. Compiler bugs

    These are mistakes made by the developers of Solidity compilers. They are practically impossible for DApp developers to detect or do anything about.

    Once a smart contract has been compiled with a bug and has been deployed on the blockchain, the bug stays. Contract deployment is final.

    It is important to note that just because a compiler has a bug, it does not at all mean that all contracts compiled with that compiler have a bug. Compilers bugs only have any negative effect in rare situations. (otherwise they would have been detected long ago, before the compiler version containing the bug was released)

You should not pay too much attention to all the warnings that etherscan.io gives. They simply look at which compiler version was used, and give a list of all known bugs for that compiler version. They don't actually do a deep analysis of every contract. Chances are, the contract you are looking at was not affected by those bugs.

It is a good idea to learn Solidity on at least a basic level, and just to read the code to see that no obvious errors were made. Errors like re-entrancy vulnerability are fairly easy to spot. Besides those, you should check for logic mistakes in the programming of the specific application you're looking at.

Some general tips:

  • A higher compiler version is in general less risky.

  • Contracts with reviewed source code are in general less risky.

  • Shorter contracts are in general less risky.

  • Contracts that have existed for a long time, have dealt with large amounts of money and have not been hacked are in general less risky.

Unfortunately, there are no guarantees to be made about all contracts.

I hope this helps somewhat.

  • Could you please explain (or link to an explanation) of what re-entrancy vulnerability is for someone who has never heard the term before? – Jonathan Lindgren Nov 27 '17 at 15:21
1

This is a good answer by @Jesse Busman, but as you can see the solidity compiler states a possible re-entrancy vulnerability, however this is only through static analysis, and the compiler does not check for modifiers. Here is a re-entrancy vulnerable function, but one that is safe:

function reEnterMe(uint256 etherAmt) onlyOwner {
   if (balances[owner] >= etherAmt){
      owner.send(etherAmt);
      balances[owner] -= etherAmt;
   }
}

Since the contract sends ether BEFORE subtracting it from the balances[owner] mapping, this function is re-enterable.

However, the onlyOwner modifier prevents ANYONE except the owner calling this contract, or it will throw. Therefore, this function is relatively safe, because who would want to re-enter their own contract?

  • I updated my question. TLTR: All the contracts use version 0.3.2! 0.3.2 is from 2016! – Hoyt Oct 20 '17 at 16:44
  • I would argue that if the widely used ethereum multi-dig contract had vulnerabilities they would have been exploited and used already. Of all contracts to be safe on the ethereum blockchain, it’s probably this one. – Alex Oct 20 '17 at 16:46
  • Of course. In fact by using version 0.3.2 and still holding 1.5 million ethereum without any exploits show great coding but I'm more concerned about the risk of new exploit rather than if it's safe now or not – Hoyt Oct 20 '17 at 16:48
  • 1
    The risk is very small. With cryptocurrency has a whole, there is always a risk. What if someone cracks keccak256 and breaks Ethereum, or sha256 and breaks bitcoin? – Alex Oct 20 '17 at 20:54
  • Could you please explain (or link to an explanation) of what re-entrancy vulnerability is for someone who has never heard the term before? – Jonathan Lindgren Nov 27 '17 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.