Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

661–670 of 754 posts

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#661

Earlier quoted context omitted.

> The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable. Actually, it's not. Regulators and ratings companies do a pretty good job of it, and in extraordinary Great Recession type events there is usually concerted response to keep consumers from incurring any losses. Insured no…

Regulators and ratings companies did a terrible job leading up to the 2008 crash, and people did have real losses. Some pensions got hit hard, for example. The loss doesn't have to come directly out of your bank account to have a real effect on you.

Exactly. Also, the cost of bad regulation is not just in the aftermath... it's mostly in the period leading up to the crash when so many billions of dollars were invested in the wrong stuff.

The great thing about the modern economy is that capital is readily available, but that doesn't mean that the massive misallocation of capital over a period of decades lacks significant consequences.

Many of the dollars mis-invested into real-estate related investments brought on by tax loophole, sloppy (if not corrupt) regulation of downside risk scenarios, and the undemocratic socialization of risk via the GSEs were all things that had a massive social cost.

To argue, as the GP does, that the regulation and management of the crisis was a success by pointing to a few selected asset prices that were the focal point of knee-jerk populist reactions to the problems is a fairly absurd way to claim success.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#663

Earlier quoted context omitted.

Can someone explain to me why they chose to make their own language instead of creating a DSL inside of an existing language?

This new language for Ethereum by Vitalik is exactly what you said: https://github.com/ethereum/viper

Viper's inspired by Python, which (for all the nice things we can say about it) is a _terrible_ place to go for inspiration for this kind of task.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#664

Earlier quoted context omitted.

> Which would make such contracts significantly more expensive than regular contracts that are reversible by trusted intermediaries and legal authorities. You assert this but don't offer proof. The cost of fraud is baked into all areas of our economic system to the point where it's very difficult to establish how much it is costing society. Arguably the massive innovations in counterfeiting prevention in the past dec…

> The larger a percentage of the economy that is transacted via a public blockchain, the less opportunity for all sorts of crime. Talk about unsupported assertions. You do realize the article you're commenting on is titled 153K Ether Stolen in Parity Multi-Sig Attack. Others have noted your confusion about what "consumer protections" means. It is patently obvious that paying out $153,000 in insurance claims would be…

I think your confusion is that you think the immutability mechanism is a flaw. Addressing the fraud should be done via insurance, since otherwise we need to trust yet another party to be sure transactions can't be mutated/reversed.

I think if you examine all the assumptions leading up to your conclusion you may find that it is erroneous.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#665
post #523

Earlier quoted context omitted.

You can also just write bytecode directly. It's a simple stack machine, and contracts should be as simple as possible.

Things are not always simpler at a lower level of abstraction.

It depends what simplicity you mean. The Solidity compiler is very far from simple, so if you consider that part of the complexity incurred by using Solidity, then a reasonably small bytecode program might be much easier to audit. Consider that a typical smart contract is as simple as "if four out of these six addresses make the same proposal then execute it." You can basically write these things in hexadecimal without too much trouble.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#666
post #514
post #476

Earlier quoted context omitted.

> That $10m out the window is like a Series A for a nefarious hacker with deep crypto skills [..] Where "deep crypto skills" refers to someone who bothered to read the documentation on Solidity (the Ethereum contract language), specifically the section on function visibility[1], and the Parity wallet contract itself[2]. In other words, an obscure security hole was not found by a genius hacker. An obvious, trivial, si…

because the people investing money in it provably didn't know what they're were doing. Very true – the price hasn't really moved in response to this news, which makes very little sense to me. I'd be shorting if I could figure out how.

Why should the price move in response to this? They'll just change the rules and print more.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#667
post #610

Earlier quoted context omitted.

>This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible. I don't see any justification for this statement. The bug could easily have been discovered if there had been better auditing. That the auditing missed the bug doesn't prove that it's "practically impossible" to write secure code with Solidity. In any case, nothing is stopping you…

> That the auditing missed the bug doesn't prove... Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do r…

>Honest question, what would be required in your opinion for before we start considering if the tool is at fault?

The programming language being partly at fault is not the same thing as it being "practically impossible" to write safe smart contracts that language, in my opinion.

I was taking issue with your wording, which I think gives a misleading impression of the attainability of secure Solidity code. Your follow up comment is more measured, as it doesn't characterise the need for some measure of luck to write a safe smart contract as writing a secure smart contract being "practically impossible".

Maybe we're using different definitions of "safe", but I think many use my definition, in which case your statement would give them a misleading impression.

>This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.

Yes I am aware of that. There is research being done on possibly switching the EVM to an Ethereum variant of Web Assembly, i.e. eWASM, which will be able to efficiently execute a wider range of functions.

Further on this point, I have to admit that I am not qualified enough to comment on the portability of Kadena to the EVM, so I'll take that back. What I meant to dispute was the notion that formally verifiable programming languages cannot be built for the EVM, which is the takeaway that I got from your comment. A PL of this type is in fact being developed [1].

Thanks for the link to the technical discussion on Solidity.

[1] https://github.com/pirapira/bamboo

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#668

Earlier quoted context omitted.

Not really true. Nothing has to be perfect if there is insurance infrastructure. People should not use contracts they have no reason to trust. As a contract becomes more important it should be viewed/vetted/trusted by as many entities as possible. Users of the contract should pay an insurance fee that goes to the vetters, who promise to reimburse in case of unpredictable behavior. Yes, this means applying some meatsp…

There are a few problems with this. 1) moral hazard/information assymetry - If I insure you against fraud I have removed most of your financial incentive to protect yourself, so I need to have some other reason to think that you will. I also need protection against the fact that you have more information than I have about the risk of fraud (how do I know you won't collude with the fraudster, in effect defraud yoursel…

These are valid and clearly articulated points. I do not disagree. I would simply point out the following:

You point out the non-trivial nature of building a system like we have today. I'd argue that Ethereum, with smart contracts and an immutable public blockchain is a useful innovation that I consider a useful building block for creating and improving the kinds of institutional relationships and interactions that you describe.

A system of insurance implemented on Ethereum would need to have the same sorts of moving parts that you describe. Ethereum would make some aspects of this harder and others far easier.

There would still be a need for collateral, escrow, etc. My comments are not meant to argue that these mechanisms become useless, they simply become more transparent and when viewed in terms of the rule of law, become significantly more resilient when markets become politicized and the rule of law is in danger of breaking down.

Things that would potentially be far easier in an Ethereum based system would be:

- assessing/auditing the books of an entity. Things like proof of solvency become much easier, and also looking at assets which are accounts receivable that depend on another entity's solvency. The modern financial system has very course-grained and inadequate ways of looking at this sort of systemic risk, which makes cascading firm failures truly devastating and nearly impossible to insure against, since any cascading firm failure will involve many ad-hoc regulatory interventions and rule changes that essentially nullify a large number of pre-existing contracts/hedges that might have existed.

- forcing precise regulations. One of the pre-2008 meatspace glitches was the too-little-too-late regulatory decision to force firms to mark certain types of assets to market even if their accounting approach determined that doing so inflated or deflated their balance sheets incorrectly. With a public ledger it would be possible to easily test a new accounting rule's impact on a firm's financial statements.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#669

Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults. All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for fun…

Your opinion about javascript and closures in particular makes me question the rest of your comment. Closures in javascript makes it easy to write async code.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#670
post #464

Earlier quoted context omitted.

> outside of the blockchain The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently. But when you introduce a non-trivial smart contract, there is a chance that it (a black box) has behavior that is not obvious from its source code. Since the behavior of the contract will cause immutable changes to the blockchain, and since humans can't…

> there must be some other mechanism for establishing that the behavior of the contract matches the common understanding of what the contract does. There is, we have been using them for hundreds of years, it is called a contract.

> it is called a contract.

Think about what puts contracts at risk.

- enforceability. If your neighbor borrows your car and agrees to pay you $20 but never does, you are screwed. With Ethereum the smart contract could lock the door to the car until funds are received. Verbal contracts for low-priced transactions are rarely enforced.

I had a landlord who simply decided not to return my deposit, so I was out $5K. He stole the money simply because I didn't have time to fly back to that city and proceed with small claims court. With Ethereum, there could be an unbiased oracle that verifies the state of an apartment at end-of-lease and allows a contract to refund the deposit as agreed. The oracle could stop by for 15 minutes on move-in day and snap some pictures, then stop by on move-out day and verify the condition and deduct any money from the deposit as previously agreed. Also the contract could enforce that the money was held in escrow as required by law.

- regulatory risk. In some cases, regulators use their aesthetic to determine that some legal contracts are (in hindsight) bad, and they wipe them out. This drastically limits the usefulness of contracts as a planning mechanism and is essentially a tax (in the form of uncertainty) on all contracts. It's like having a buggy VM that does things arbitrarily differently now and then.

- higher confidence in the outcome of a contract. With paper meatspace contracts, the language is hard to understand and is pieced together from legal boilerplate based on court decisions where the court interpreted a sentence to mean something precise, etc. This makes these contracts difficult for a layperson to understand even though they are written in English. When you sign a contract you don't know how many times it has been reviewed by a court and whether the court found any of it to be unenforceable or to otherwise mean something different from what you think it means when you sign it.

We are always signing TOS agreements, license agreements, leases, waivers, etc. etc. Most of these are virgin legal territory, untested in the court system and designed by lawyers to be overly aggressive in favor of the entity the consumer is doing a transaction with. While it's great that all these contracts might one day be reviewed by a court if the stakes get high enough, a much better approach would be to have very simple, easily enforceable terms. How many unique smart contracts for doing insurance does the world need? Probably about as many as it needs AES implementations. Code that matters would be reviewed with far more scrutiny than most verbal contracts ever get, and composing contracts would also be far easier with well-defined, vetted behavior.

Post reply on HN