153k Ether Stolen in Parity Multi-Sig Attack

Re:153k Ether Stolen in Parity Multi-Sig Attack by simias on Thursday July 20, 2017 @08:07AM (#14811711)

Most of the issues pointed out by int_19h would be handled at compile time during static analysis and wouldn't change much to the generated bytecode. I'm talking about strong typing, immutability by default, less error-prone syntax, tail calls, evaluation order etc...

Even replacing 256bit ints with arbitrary precision "bigints" wouldn't add too much of a cost if it's a native type of the underlying VM (as it should be for such an application IMO). It might even reduce code size by removing overflow tests.

[ Parent | on HN ]

Re:153k Ether Stolen in Parity Multi-Sig Attack by int_19h on Thursday July 20, 2017 @05:05PM (#14816290)

It's about costing the operations reliably.

But I would still expect arithmetic to be overflow-checked by default, as in e.g. VB.NET. This would mean that careless arithmetic on unvalidated inputs could still cause the contract to fail - but at least it would be a controllable failure, with all state changes being reversed, and hence not exploitable.

[ Parent | on HN ]

Re:153k Ether Stolen in Parity Multi-Sig Attack by earlz on Thursday July 20, 2017 @12:59PM (#14814238)

In the rationale document they explain that arbitrary length integers were too difficult to determine a reasonable gas cost around for math etc.

[ Parent | on HN ]