[jazzyjackson]

My guess is Integer VS Float.

Take a typical $23 transaction fee, which comes out to ~0.00775756 ETH

Of course, everyone knows you don't want to do math as floating point, you want to use an integer representation. 1 ETH can be divided into 1e18 "Wei" or 1e9 "GigaWei".

So that 23 USD could be expressed an an integer "7757560", with the expectation that the decimal point would get moved 9 points <- thataway to become 0.00775756 ETH

If somewhere in your code you do some kind of money formatting that turns 7757560 GWEI into 7757.56 ETH, you've got your $23,000,000 USD mining fee.

[xvilka]

This is why in "classic" fintech they used so-called "decimal" fixed-point numbers for decades. To not use COBOL as an example let's check something more modern, e.g. Rust[1].

[1] https://github.com/paupino/rust-decimal

[MichaelBurge]

Ethereum uses integers to store transaction amounts internally. Integers are fixed-point already, so that library is completely irrelevant.

[xvilka]

I didn't mean Ethereum itself, apparently the bug is in whatever code written at the higher level, inside the exchange or whatever service they use.

[jallen_dot_dev]

This sounds about right but I think the mistake is a little bit simpler. In an eth transaction you don't actually specify the total fee, you specify the gas price. In the raw transaction it is measured in wei. But in UIs it is common to represent price in gwei (see e.g. https://ethgasstation.info/).

So instead of a bug in converting gwei to eth, I bet somebody thought they were specifying the raw price in wei but the input box assumes gwei and does a x1000000000.

[ericwood]

It looks like you were pretty much correct: https://blog.deversifi.com/23-7-million-dollar-ethereum-tran...

[ajsharp]

you win HN today, jazzy

[csomar]

But then, they should have basic "high mining" fees checks. My Trezor does have that.

[quotemstr]

My position for ages now has been that it was a mistake to make floating point types first-class primitives in most programming languages. Integers and rationals should be the go-to types for most code most of the time. If you really need a IEEE float, you should reach into a library to get it.

[kevinpet]

Well, this isn't very strong support for that position, because Ethereum doesn't support floating point, and yet here we are.

[jonny_eh]

> Ethereum doesn't support floating point

The software that interacts with it does.

[rightbyte]

I think you mixed up the problem. Had they used floats they would have got a small rounding error, not a 23 million loss.

[mhh__]

So all companies will automatically include the float library and thus nothing will change

[WillDaSilva]

What you include as a first-class element in your languages, versus what is packed away in a library, will affect what developers do with your language.

For instance, Numpy provides array-language [1] capabilities to Python, but because it isn't a first-class element in the language Python is not thought of as an array language, and using it as one would be a bit clunky.

[1] https://en.wikipedia.org/wiki/Array_programming

[webkike]

If the only thing you use computers for is processing financial transactions then that position is defendable

[beachy]

Any number of sensors, measuring devices and other IoT stuff disagrees with you.

[MuffinFlavored]

Dumb question on my end, I apologize.

How are rationals used to represent decimals?

[dragonwriter]

> How are rationals used to represent decimals?

Decimals are just the subset of rationals where the denominator is always a power of 10, so the representation and arithmetic operations are simple if you already have rational support (though if you need to preserve decimal results, you need approximation logic for division, since dividing two rationals with denominators that are powers of 10 may result in a rational with a denominator that is not a power of 10.)

[thaumasiotes]

> though if you need to preserve decimal results, you need approximation logic for division, since dividing two rationals with denominators that are powers of 10 may result in a rational with a denominator that is not a power of 10.

This is also true for adding, subtracting, and multiplying, though in those cases it is always trivial to convert the result into a form where the denominator is a power of 10.