1. 18

  2. 14

    “This means that currently no funds can be moved out of the multi-sig wallets.”

    Don’t really look like a security alert, looks like, your money is lost in a black hole

    1. 6

      I don’t mean to be a party pooper, but the obvious (as in first sentence of difference) between: https://en.bitcoin.it/wiki/Script vs the ethereum VM is that (1) you can write bugs into both (2) but you can much more easily write really bad bugs which only appear at scale in ethereum. This isn’t a deep technical analysis, it just an obvious difference. A lot more surface area for attacks and mistakes to appear on with Ethereum. That’s of course a huge benefit, these programmable contracts, but without any sort of mechanical proofs of code deployed to the EVM it seems like folks are apt to be exposed to varieties bug classes for the foreseeable future. Until such proofs are require, ethereum is just bugs as a service with some speculative (and realizable) value attached.

      1. 3

        issue was triggered accidentally 6th Nov 2017 02:33:47 PM +UTC and subsequently a user suicided the library-turned-into-wallet, wiping out the library code which in turn rendered all multi-sig contracts unusable since their logic (any state-modifying function) was inside the library.

        Wait, what the fuck? Do I understand correctly the supposed-to-be-smart wallets/contracts/entities are depending on external entities for core business logic? Is this the leftpad again?

        1. 6

          No, they can only reuse code from the blockchain.

          Apparently the Ethereum VM has a SUICIDE instruction. Parity’s library for multi-signature wallets had a function that calls it:

            // kills the contract sending everything to `_to`.
            function kill(address _to) onlymanyowners(sha3(msg.data)) external {

          Intended to be called in the contracts that inherit it from the library.

          But the library owner had the ability to call it directly on the library itself. And the library was not initialized as a contract would be (so, it didn’t have an owner) so a random person just… owned it (sorry) and called that function. And all the contracts now inherited the deletion of library functions.

        2. 3

          Great comment on Hacker News about what happened:


          1. 3

            Not even a full year after the DAO hack.

            Will Ethereum ever manage to develop a programmable blockchain without bugs?

            1. 6

              This is functionally equivalent to developing software in general without bugs.

              We all know how easy that is.

              1. 4

                I.e. it’s doable if the work is competent and thorough. I would not use either of these terms to describe anything about ethereum.

                On the other hand, a promising development here, which will hopefully be applied to Bitcoin in the future: https://blockstream.com/simplicity.pdf

                1. 2

                  I think the challenge comes from the complexity of smart contracts. Bitcoin has never had bugs this bad, but Bitcoin is not programmable.

                  Ethereum changes too quickly for me to keep up - are these programmable contracts Turing-complete? Their chain might be more secure if the smart contract language was less powerful. Simple languages are a lot easier to reason about, and to prove the safety of.

                  1. 2

                    Bitcoin is programmable to a certain extent (you can do escrow for example) but it has not a turing complete language. I totally agree that their smart contract language should not be turing complete

                  2. 2

                    John Nagle (Animats) suggested Decision Tables since they can be setup to be quite intuitive and analyzed by machines:


                    One can also apply lessons from Design by Contract to embed constraints. One might also have the transaction generate traces that have to be sanity checked in a pre-agreed-upon way. There’s stuff that blockchains might explore that don’t require fancy programming languages so much as increasing clarity for people writing the contracts.

                    1. 1

                      it is a beautiful idea

                  3. 3

                    It’s the same problem as any other programming environment: people will build programs that have bugs, and while the environment can and should work to eliminate software errors, we will always invent new classes of bugs that will require extensive research to understand, detect, and prevent.

                  4. 2
                    1. 2

                      Label: P0-dropeverything

                      Oh, everything’s dropped alright…