16 ms·

Here's the root error I believe: https://github.com/paritytech/parity/blob/master/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/parityte

by earlz 9y ago

Here's the root error I believe: https://github.com/paritytech/parity/blob/master/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/master/js/src/cont... The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control

dvcc 9y ago
Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.
- TylerE 9y ago
  Because the cryptocurrency space attracts only the brightest minds.
  - wheelerwj 9y ago
    i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes. the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
    - kbenson 9y ago
      I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals. They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense. If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
      - davidgerard 9y ago
        Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success. I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
        kbenson 9y ago
        That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
        dahdum 9y ago
        Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top. As far as I can remember, the EVM has never failed, just programmers.
        kbenson 9y ago
        That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time. The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
        shp0ngle 9y ago
        I disagree, Solidity is really not easy to learn. It is easy to screw up, though.
    - eropple 9y ago
      One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
      - wheelerwj 9y ago
        That's a valid point. But its hard to be humble when you work on something that was designed to topple national banks.
        eropple 9y ago
        Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.) If it's important, you need to be good. If it's very important, you need to be good and sure.
        wheelerwj 9y ago
        I don't disagree, it's just easier said than done.
    - moeop 9y ago
      These mistakes are predictable and inexcusable. The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable. This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation. It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
      - wheelerwj 9y ago
        you don't think 200m ico's counts as marketing traction? This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
      - youdontknowtho 9y ago
        I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
        munin 9y ago
        You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
    - geofft 9y ago
      > But if banks and major retailers who have huge budgets can get hacked, of course we can too. Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked". When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny. When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day. The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website. There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
      - nipponese 9y ago
        From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
        geofft 9y ago
        I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?) However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point. Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed). If you really want a simple point out of me, I think G. K. Chesterton made it in 1929: > In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
    - shp0ngle 9y ago
      The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography. But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
  - PhasmaFelis 9y ago
    My favorite smack-talk so far is "Dunning-Krugerrands".
    - i_am_nomad 9y ago
      That is certified brilliant.
    - kcanini 9y ago
      That pun is golden.
      - posterboy 9y ago
        would've missed it, thx
  - dang 9y ago
    Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics? You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
  - honestoHeminway 9y ago
    If you have such a bright mind, you often need a dark hat, to avoid blinding the others.
- elviejo 9y ago
  For the same reason every variable in JavaScript is global by default... I.e. I don't have a clue how that could seem like a good idea.
  - koolba 9y ago
    That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default. But yes it seems pretty asinine to use global by default for (not so) smart contracts.
    - Klathmon 9y ago
      And even that undeclared-are-global thing is gone in modern js. It's explicitly an error in strict mode.
    - saurik 9y ago
      Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".
    - oelmekki 9y ago
      Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode". Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino. The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
- deleted 9y ago
  [deleted]
- lomnakkus 9y ago
  It's a good indicator that these people may be experts in one area, but not necessarily in others. Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.) [1] Beyond surface-level, obviously. [2] We're talking about 0.0001% of the general population here.
  - Claire88 9y ago
    my stepmother recently got a nice twelve month old Nissan Rogue SUV only from working part time off a macbook air. visit this page>>>>>>>>http://www.joinmate2.com http://www.joinmate2.com chek it site.
  - buckie 9y ago
    > Not just proof of "design", but proof of the implementation. Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare. In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2]. The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed. Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist. [1]: https://youtu.be/Nw1glriQYP8?t=1071 https://youtu.be/Nw1glriQYP8?t=1071 [2]: kadena.io/pact
    - lomnakkus 9y ago
- firebones 9y ago
  Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public. Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal. It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way. [1] http://solidity.readthedocs.io/en/develop/contracts.html#visibility-and-getters http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#function-types http://solidity.readthedocs.io/en/develop/types.html#functio...
- imron 9y ago
  Imagine the court case: Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
  - blunte 9y ago
    I cannot imagine the court case. The courts are utterly incapable of understanding enough of the technical aspects of far simpler software cases. So like most court cases, it will simply be a matter of human influence winning the case.
    - macmac 9y ago
      If you are interested in a really good counter example to your assertion you should look at Judge Alsup https://www.techdirt.com/articles/20170325/23492137003/judge-alsup-wants-uber-waymo-to-teach-him-how-to-lidar-prior-to-self-driving-car-case.shtml https://www.techdirt.com/articles/20170325/23492137003/judge...
Scaevolus 9y ago
Good catch! It is indeed that the constructor could be called by anyone. Here's a couple txns showing it: Calling initwallet: https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577a7d48cb73c2f51f149c0bf96b29660 https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577... Executing: https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c9b681a77fef1693b0badbb6afdb083 https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c...
Analemma_ 9y ago
> Unmarked functions default to public in Solidity What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.
- justinjlynn 9y ago
  Design... before Solidarity I had never seen such an abuse of the word.
  - hirsin 9y ago
    I think the capitalization of a method making the difference between two very different outcomes might be my favorite example. It's that kind of stuff that makes me happy I have to go through api reviews at work - although seriously how does anyone sign off on these designs?
    - justinjlynn 9y ago
      > sign off on these designs I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.
- Animats 9y ago
  This is why I keep saying that "smart contracts" should be expressed in some declarative notation like decision tables. Byte-coded programs as contracts were a really bad idea. Contracts need to be readable, not just executable.
  - dvcc 9y ago
    I'm kind of curious on what you think about Tezos and its Michelson language (https://www.tezos.com/static/papers/language.pdf https://www.tezos.com/static/papers/language.pdf) which offers provability of contracts.
naasking 9y ago
> Unmarked functions default to public in Solidity Facepalm Wasn't this lesson learned long ago? C# defaults to private on unmarked members. Why would you ever want to default public?
- deleted 9y ago
  [deleted]
- tinco 9y ago
  It was designed to be like Javascript. Of all languages...
  - dom96 9y ago
    Wouldn't it make more sense to design it like Haskell? or something even more strict? A little bit of extra work seems like a small price to pay to prevent millions being stolen from your wallet because of a silly mistake like this...
    - quickthrower 9y ago
      In Haskell everything is public by default unless you specify exports for the module.
      - aisofteng 9y ago
        But it also has a statically checked type system.
        quickthrower 9y ago
        I think if done in Haskell how good or bad it is depends on the chosen abstraction for effects not Haskell itself. Haskell is a good basis but the developers need to make the API fool proof. E.g. expose limited effects rather than a big fat "IO" type.
dna_polymerase 9y ago
I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"
- easytiger 9y ago
  In that future, ironically, Gold acquires even more value as a hedge
- justinjlynn 9y ago
  "It's all there black and white, clear as crystal. [...] You get nothing. You lose. Good day, sir."
  - sdenton4 9y ago
    Furthermore, I suggest you do what your parents did, and get a job, sir! The bums lost, Lebowski!
  - jeffwass 9y ago
    You skipped the juiciest part of one of my favorite scenes of that movie. [scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him]. So I feel obligated to post the full bit (from wikiquote) >Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]
    - secabeen 9y ago
      >[scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him]. Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.
corysama 9y ago
Hmmm... That's similar to, but not covered by this submitted fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...
sidthekid 9y ago
Seems like something a code review would have caught. Then again, code reviews and other slow processes are probably not the par for startups.
- pas 9y ago
  Or just dumb fuzzing. Or a testnet. Or whatever the fancy word for static verification is nowadays.
- DennisP 9y ago
  About half my day job is auditing Solidity code for startups. And yes this should have been caught.
  - zdkl 9y ago
    Auditing Solidity? Sounds sexy and infernal at the same time. Congratudolences I guess?
  - glitch003 9y ago
    Can you share where you work? I'm looking for someone to audit some Solidity code.
- mechnesium 9y ago
  Precisely. Code reviews and software quality assurance aren't just corporate redtape, they can save your rear.
  - Cthulhu_ 9y ago
    Especially for this; it should be enterprise, bank-tier code, covered by as much red tape as possible. The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.
    - 9y ago
cslarson 9y ago
Why doesn't the only_uninitialized modifier cause a throw since m_numOwners should have already been > 0, no?
- ago 9y ago
  It got patched after he posted this. Before that there was no only_uninitialized.
greato 9y ago
Does this mean ETC is compromised too?
- baligad 9y ago
  The vulnerability being discussed is for a particular multi-sig wallet, not the Ethereum blockchain itself.
- gus_massa 9y ago
  This is not a problem in ETH [1]. It's a bug in one of the contracts written by Parity. Anyone that has (had) money in these specific contracts is in trouble. If you are not using these specific contracts, you are safe (for now). ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains. So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC. To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1]. [1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.
- 5chdn 9y ago
  Not directly, but Parity multi-signagure wallets on Ethereum Classic, Expanse, Musicoin, and other public chains are affected as well.
theptip 9y ago
Poking around in that project, I don't see any specific tests of the Wallet contract... would be interested to see what UTs/STs were included if anyone knows where they are -- or was it just manually tested on the testnet? It seems that a basic set of UTs for this contract should have caught this issue. It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE). There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain). If you are considering writing a smart contract, read and re-read https://github.com/ConsenSys/smart-contract-best-practices https://github.com/ConsenSys/smart-contract-best-practices, and then write UTs for each of these cases so that you can convince yourself that you've covered them. Relevant to this bug: > Understand that your public functions are public, and may be called maliciously. Your private data is also viewable by anyone.
- kmf 9y ago
  I've been writing some smart contracts over the last couple weeks and have learned a lot from OpenZeppelin's solidity repo–you can either use them directly (importing and extending off of them) or use them as a good resource for building tokens, crowdsales, etc–can't recommend them enough. https://github.com/OpenZeppelin/zeppelin-solidity https://github.com/OpenZeppelin/zeppelin-solidity
  - hrpnk 9y ago
    Agreed, it's definitely the way to go. Hope the project will continue to evolve. Both Aragon [0] and Storj [1] are making active use of them, if you look for example usage. [0] https://github.com/aragon/aragon-network-token https://github.com/aragon/aragon-network-token [1] https://github.com/Storj/storj-contracts https://github.com/Storj/storj-contracts
- legolassexyman 9y ago
  As I said here last week "Also the lead developer is some kid who believes very much in moving fast and breaking things. This philosophy may work for a social network site but not for other people's money." This philosophy permeates the community of Etherum development. Bitcoin disabled most of the smart contracts op codes for a very good reason. I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.
plainOldText 9y ago
That is correct! Here's their proposed fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...
shurcooL 9y ago
Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else. Based on the time of your post, I suspect you meant to link to: https://github.com/paritytech/parity/blob/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...
- nh2 9y ago
  You just saved me hours of life time
- sillysaurus3 9y ago
  That Y hotkey is immensely useful. Thanks!
- git-pull 9y ago
  Some explanation of what's happening here: The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/master/js/src/cont... Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line. The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1]. Like this: https://github.com/paritytech/parity/blob/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177ef3f4521c66... You could also do it with the short ref (4c32177e): https://github.com/paritytech/parity/blob/4c32177e/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177e/js/src/co... Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2]. If you click the line number on a GitHub file, it will add the #LineNumber to your URL. From there, press Y, this will replace master with the latest commit of the repo. [1] https://git-scm.com/book/en/v2/Git-Internals-Git-References https://git-scm.com/book/en/v2/Git-Internals-Git-References [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
xrd 9y ago
This seems like a compiler bug, not a systemic issue with Ethereum. No?
- fab13n 9y ago
  It's a bug in a smart contract, but the root cause is the bug-prone design of Solidity. It's hard to write bug-free code in Solidity (or anything targetting EVM actually), and nearly impossible to be confident that a given contract is bug-free. parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract? How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?
slackingoff2017 9y ago
"Solidity" is a pretty sarcastic name for the language at this point :)
- defined 9y ago
  Did you mean "ironic"?
  - slackingoff2017 9y ago
    Perhaps both :)
    - aisofteng 9y ago
      For an uttering to be sarcastic it needs to have been intended to be so.
mrb 9y ago
That's correct. Here is a more detailed explanation: https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7 https://blog.zeppelin.solutions/on-the-parity-wallet-multisi...
vuyani 9y ago
But also, a quick fix to this is to add a modifier that throws if m_owners[1] is already initialized

by earlz 9y ago

dvcc 9y ago

Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.

TylerE 9y ago
Because the cryptocurrency space attracts only the brightest minds.
- wheelerwj 9y ago
  i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes. the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
  - kbenson 9y ago
    I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals. They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense. If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
    - davidgerard 9y ago
      Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success. I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
      - kbenson 9y ago
        That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
        dahdum 9y ago
        Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top. As far as I can remember, the EVM has never failed, just programmers.
        kbenson 9y ago
        That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time. The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
        shp0ngle 9y ago
        I disagree, Solidity is really not easy to learn. It is easy to screw up, though.
  - eropple 9y ago
    One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
    - wheelerwj 9y ago
      That's a valid point. But its hard to be humble when you work on something that was designed to topple national banks.
      - eropple 9y ago
        Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.) If it's important, you need to be good. If it's very important, you need to be good and sure.
        wheelerwj 9y ago
        I don't disagree, it's just easier said than done.
  - moeop 9y ago
    These mistakes are predictable and inexcusable. The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable. This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation. It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
    - wheelerwj 9y ago
      you don't think 200m ico's counts as marketing traction? This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
    - youdontknowtho 9y ago
      I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
      - munin 9y ago
        You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
  - geofft 9y ago
    > But if banks and major retailers who have huge budgets can get hacked, of course we can too. Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked". When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny. When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day. The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website. There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
    - nipponese 9y ago
      From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
      - geofft 9y ago
        I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?) However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point. Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed). If you really want a simple point out of me, I think G. K. Chesterton made it in 1929: > In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
  - shp0ngle 9y ago
    The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography. But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
- PhasmaFelis 9y ago
  My favorite smack-talk so far is "Dunning-Krugerrands".
  - i_am_nomad 9y ago
    That is certified brilliant.
  - kcanini 9y ago
    That pun is golden.
    - posterboy 9y ago
      would've missed it, thx
- dang 9y ago
  Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics? You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
- honestoHeminway 9y ago
  If you have such a bright mind, you often need a dark hat, to avoid blinding the others.
elviejo 9y ago
For the same reason every variable in JavaScript is global by default... I.e. I don't have a clue how that could seem like a good idea.
- koolba 9y ago
  That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default. But yes it seems pretty asinine to use global by default for (not so) smart contracts.
  - Klathmon 9y ago
    And even that undeclared-are-global thing is gone in modern js. It's explicitly an error in strict mode.
  - saurik 9y ago
    Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".
  - oelmekki 9y ago
    Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode". Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino. The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
deleted 9y ago
[deleted]
lomnakkus 9y ago
It's a good indicator that these people may be experts in one area, but not necessarily in others. Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.) [1] Beyond surface-level, obviously. [2] We're talking about 0.0001% of the general population here.
- Claire88 9y ago
  my stepmother recently got a nice twelve month old Nissan Rogue SUV only from working part time off a macbook air. visit this page>>>>>>>>http://www.joinmate2.com http://www.joinmate2.com chek it site.
- buckie 9y ago
  > Not just proof of "design", but proof of the implementation. Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare. In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2]. The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed. Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist. [1]: https://youtu.be/Nw1glriQYP8?t=1071 https://youtu.be/Nw1glriQYP8?t=1071 [2]: kadena.io/pact
  - lomnakkus 9y ago
firebones 9y ago
Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public. Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal. It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way. [1] http://solidity.readthedocs.io/en/develop/contracts.html#visibility-and-getters http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#function-types http://solidity.readthedocs.io/en/develop/types.html#functio...
imron 9y ago
Imagine the court case: Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
- blunte 9y ago
  I cannot imagine the court case. The courts are utterly incapable of understanding enough of the technical aspects of far simpler software cases. So like most court cases, it will simply be a matter of human influence winning the case.
  - macmac 9y ago
    If you are interested in a really good counter example to your assertion you should look at Judge Alsup https://www.techdirt.com/articles/20170325/23492137003/judge-alsup-wants-uber-waymo-to-teach-him-how-to-lidar-prior-to-self-driving-car-case.shtml https://www.techdirt.com/articles/20170325/23492137003/judge...

Scaevolus 9y ago

Good catch! It is indeed that the constructor could be called by anyone. Here's a couple txns showing it: Calling initwallet: https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577a7d48cb73c2f51f149c0bf96b29660 https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577... Executing: https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c9b681a77fef1693b0badbb6afdb083 https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c...

Analemma_ 9y ago

> Unmarked functions default to public in Solidity What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.

justinjlynn 9y ago
Design... before Solidarity I had never seen such an abuse of the word.
- hirsin 9y ago
  I think the capitalization of a method making the difference between two very different outcomes might be my favorite example. It's that kind of stuff that makes me happy I have to go through api reviews at work - although seriously how does anyone sign off on these designs?
  - justinjlynn 9y ago
    > sign off on these designs I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.
Animats 9y ago
This is why I keep saying that "smart contracts" should be expressed in some declarative notation like decision tables. Byte-coded programs as contracts were a really bad idea. Contracts need to be readable, not just executable.
- dvcc 9y ago
  I'm kind of curious on what you think about Tezos and its Michelson language (https://www.tezos.com/static/papers/language.pdf https://www.tezos.com/static/papers/language.pdf) which offers provability of contracts.

naasking 9y ago

> Unmarked functions default to public in Solidity Facepalm Wasn't this lesson learned long ago? C# defaults to private on unmarked members. Why would you ever want to default public?

deleted 9y ago
[deleted]
tinco 9y ago
It was designed to be like Javascript. Of all languages...
- dom96 9y ago
  Wouldn't it make more sense to design it like Haskell? or something even more strict? A little bit of extra work seems like a small price to pay to prevent millions being stolen from your wallet because of a silly mistake like this...
  - quickthrower 9y ago
    In Haskell everything is public by default unless you specify exports for the module.
    - aisofteng 9y ago
      But it also has a statically checked type system.
      - quickthrower 9y ago
        I think if done in Haskell how good or bad it is depends on the chosen abstraction for effects not Haskell itself. Haskell is a good basis but the developers need to make the API fool proof. E.g. expose limited effects rather than a big fat "IO" type.

dna_polymerase 9y ago

I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"

easytiger 9y ago
In that future, ironically, Gold acquires even more value as a hedge
justinjlynn 9y ago
"It's all there black and white, clear as crystal. [...] You get nothing. You lose. Good day, sir."
- sdenton4 9y ago
  Furthermore, I suggest you do what your parents did, and get a job, sir! The bums lost, Lebowski!
- jeffwass 9y ago
  You skipped the juiciest part of one of my favorite scenes of that movie. [scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him]. So I feel obligated to post the full bit (from wikiquote) >Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]
  - secabeen 9y ago
    >[scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him]. Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.

corysama 9y ago

Hmmm... That's similar to, but not covered by this submitted fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...

sidthekid 9y ago

Seems like something a code review would have caught. Then again, code reviews and other slow processes are probably not the par for startups.

pas 9y ago
Or just dumb fuzzing. Or a testnet. Or whatever the fancy word for static verification is nowadays.
DennisP 9y ago
About half my day job is auditing Solidity code for startups. And yes this should have been caught.
- zdkl 9y ago
  Auditing Solidity? Sounds sexy and infernal at the same time. Congratudolences I guess?
- glitch003 9y ago
  Can you share where you work? I'm looking for someone to audit some Solidity code.
mechnesium 9y ago
Precisely. Code reviews and software quality assurance aren't just corporate redtape, they can save your rear.
- Cthulhu_ 9y ago
  Especially for this; it should be enterprise, bank-tier code, covered by as much red tape as possible. The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.
  - 9y ago

cslarson 9y ago

Why doesn't the only_uninitialized modifier cause a throw since m_numOwners should have already been > 0, no?

ago 9y ago
It got patched after he posted this. Before that there was no only_uninitialized.

greato 9y ago

Does this mean ETC is compromised too?

baligad 9y ago
The vulnerability being discussed is for a particular multi-sig wallet, not the Ethereum blockchain itself.
gus_massa 9y ago
This is not a problem in ETH [1]. It's a bug in one of the contracts written by Parity. Anyone that has (had) money in these specific contracts is in trouble. If you are not using these specific contracts, you are safe (for now). ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains. So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC. To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1]. [1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.
5chdn 9y ago
Not directly, but Parity multi-signagure wallets on Ethereum Classic, Expanse, Musicoin, and other public chains are affected as well.

theptip 9y ago

Poking around in that project, I don't see any specific tests of the Wallet contract... would be interested to see what UTs/STs were included if anyone knows where they are -- or was it just manually tested on the testnet? It seems that a basic set of UTs for this contract should have caught this issue. It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE). There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain). If you are considering writing a smart contract, read and re-read https://github.com/ConsenSys/smart-contract-best-practices https://github.com/ConsenSys/smart-contract-best-practices, and then write UTs for each of these cases so that you can convince yourself that you've covered them. Relevant to this bug: > Understand that your public functions are public, and may be called maliciously. Your private data is also viewable by anyone.

kmf 9y ago
I've been writing some smart contracts over the last couple weeks and have learned a lot from OpenZeppelin's solidity repo–you can either use them directly (importing and extending off of them) or use them as a good resource for building tokens, crowdsales, etc–can't recommend them enough. https://github.com/OpenZeppelin/zeppelin-solidity https://github.com/OpenZeppelin/zeppelin-solidity
- hrpnk 9y ago
  Agreed, it's definitely the way to go. Hope the project will continue to evolve. Both Aragon [0] and Storj [1] are making active use of them, if you look for example usage. [0] https://github.com/aragon/aragon-network-token https://github.com/aragon/aragon-network-token [1] https://github.com/Storj/storj-contracts https://github.com/Storj/storj-contracts
legolassexyman 9y ago
As I said here last week "Also the lead developer is some kid who believes very much in moving fast and breaking things. This philosophy may work for a social network site but not for other people's money." This philosophy permeates the community of Etherum development. Bitcoin disabled most of the smart contracts op codes for a very good reason. I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.

plainOldText 9y ago

That is correct! Here's their proposed fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...

shurcooL 9y ago

Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else. Based on the time of your post, I suspect you meant to link to: https://github.com/paritytech/parity/blob/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...

nh2 9y ago
You just saved me hours of life time
sillysaurus3 9y ago
That Y hotkey is immensely useful. Thanks!
git-pull 9y ago
Some explanation of what's happening here: The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/master/js/src/cont... Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line. The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1]. Like this: https://github.com/paritytech/parity/blob/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177ef3f4521c66... You could also do it with the short ref (4c32177e): https://github.com/paritytech/parity/blob/4c32177e/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blob/4c32177e/js/src/co... Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2]. If you click the line number on a GitHub file, it will add the #LineNumber to your URL. From there, press Y, this will replace master with the latest commit of the repo. [1] https://git-scm.com/book/en/v2/Git-Internals-Git-References https://git-scm.com/book/en/v2/Git-Internals-Git-References [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

xrd 9y ago

This seems like a compiler bug, not a systemic issue with Ethereum. No?

fab13n 9y ago
It's a bug in a smart contract, but the root cause is the bug-prone design of Solidity. It's hard to write bug-free code in Solidity (or anything targetting EVM actually), and nearly impossible to be confident that a given contract is bug-free. parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract? How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?

slackingoff2017 9y ago

"Solidity" is a pretty sarcastic name for the language at this point :)

defined 9y ago
Did you mean "ironic"?
- slackingoff2017 9y ago
  Perhaps both :)
  - aisofteng 9y ago
    For an uttering to be sarcastic it needs to have been intended to be so.

mrb 9y ago

That's correct. Here is a more detailed explanation: https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7 https://blog.zeppelin.solutions/on-the-parity-wallet-multisi...

vuyani 9y ago

But also, a quick fix to this is to add a modifier that throws if m_owners[1] is already initialized