8 ms·

Round error issue - produce money for free on itBit bitcoin exchange

70 points by waffle_ss 10y ago

mikeash 10y ago
Sounds like someone used floating point to store currency. Bad idea, unless it's part of a macroeconomics model or something.
- AtheistOfFail 10y ago
  This is why when doing currency, you store in the lowest denomination possible and use whole number (if doing dollars, store cents in integers)
  - mikeash 10y ago
    Exactly. (And yes, it's good to point out the right way, not just the wrong way!) I've heard of some applications using tenths of a cent since they needed more precision. For Bitcoin applications, I think you'd want to work in integer satoshis.
    - Declanomous 10y ago
      The default currency type I've seen used for accounting is a decimal with 4 digits trailing the decimal. I forget the leading digits, but it is something like 14. Basically I think the idea with 4 digits after the decimal is that the smallest denomination you can have is 1 penny, and that allows you to calculate percentages of pennies accurately to a hundredth of a percentage point.
    - andrepd 10y ago
      What if you have to calculate, say, a 0.5% fee on a few satoshis?
      - AtheistOfFail 10y ago
        Calculate it and round it off after calculation to the nearest satoshi.
  - danbruc 10y ago
    That does not solve the problem in general, you still may end up with fractional quantities if you, for example, calculate a 1% fee. The correct way to do it is to use a decimal floating point format AND carefully pay attention to rounding. Also note the the way you round usually depends on the context, for some calculations you want to round up, for some down, and for some in yet another way. So you perform explicit rounding with an explicit rounding mode everywhere it is required and don't assume that implicit rounding or the default rounding mode will do the right thing because they won't in general. EDIT: To expand a bit on the context. If you, for example, charge a percentage fee you can choose between rounding up getting at least the fee you are asking for or rounding down not charging the customer more than you are asking for. Or you can try to be less biased and round either up or down depending on the fractional part. This may still require tie-breaking, either in a direction of your choice, or randomized, or by some rule like round half to even. Different choices will obviously have different biases. While this may almost seem somewhat pedantic, such things have been exploited, see for example »Computer Capers: Tales of Electronic Thievery, Embezzlement & Fraud«. [1][2] Also note that there may be even legal regulations prescribing how you can and can not round, for example between the Euro and the replaced national currencies. [3] I also have some faint memories of a case against someone systematically exploiting rounding errors but I can not come up with a reference and may even misremember this. [1] http://www.snopes.com/business/bank/salami.asp http://www.snopes.com/business/bank/salami.asp [2] https://www.amazon.com/Computer-Capers-Electronic-Thievery-Embezzlement/dp/069001743X https://www.amazon.com/Computer-Capers-Electronic-Thievery-E... [3] http://www.sysmod.com/eurofaq.htm#ROUNDING http://www.sysmod.com/eurofaq.htm#ROUNDING
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - mikeash 10y ago
      Won't decimal floats still result in errors like this if the absolute value gets too large? You can avoid that by ensuring that the mantissa has enough digits to hold the largest value you'll ever encounter with enough significance to represent the smallest value you'll ever encounter, but at that point you might as well use an integer with that smallest value as the unit.
  - SolarNet 10y ago
    Or use a language with arbitrary precision numbers (they are only like 50 years old so I can see why many people don't use them /s). As someone else already pointed out, this still prevents calculations of fees as a percentage, and other issues.
    - waqf 10y ago
      C'mon, the Egyptians had arbitrary precision numbers.
    - mikeash 10y ago
      Don't you still have to be smart about rounding at some point? Otherwise compounding a (say) 1% fee will lead to arbitrarily long numbers.
      - SolarNet 10y ago
        Yes. But then you write that at the boundary. Along with the other consistency checks. And you are forced to think about it at the appropriate time, instead of forgetting about it entirely (floats) or introducing subtle errors (integers, and then likely casting it to a float to calculate 1% and then adding it back by casting back to an integer; hint: that's also a bad idea because it has floats in it - which as we've learned recently on HN - are not that deterministic or precise).
        mikeash 10y ago
        Let's say you're not a complete idiot and avoid the use of floats altogether, what subtle errors would you avoid by using arbitrary precision numbers over integers?
        SolarNet 10y ago
        Well first riddle me this. How do you calculate a ⅓% (1 / 3 of a percent) fee with integers. Depending on your choice of solution I can tell you how it has a problem and how arbitrary precision numbers would solve it.
  - sp332 10y ago
    I think banks keep track of calculations (like interest) down to the 4th decimal place, 1/10,000 of a penny. Then they round to the nearest cent when settling.
  - cwmma 10y ago
    the lowest denomination of the dollar is the mill not the cent.
  - spc476 10y ago
    There are still items in the US that use mills (1/1000 of a dollar). Two examples: property tax and gas.
koolba 10y ago
Those that do not understand why floating point math has no place in the world of money are doomed to repeat this mistake. Over and over and over ... The snippet of what I presume is their API response is interesting: {"currencyCode":"XBT","balance":100000.00000008,"available":100000.00000008,"onDeposit":0} The amount fields are JSON numbers. That's fine for integers up to 2^52[1] but can have issues with floating point math. They'd be better off representing everything as satoshis and doing integer math on everything. I bet their entire system is based on floating point math. Tisk tisk ... [1]: Yes probably not an issue unless your Bill Gates and convert your networth to Zimbabwean dollars...
- Kenji 10y ago
  As someone who is trying to get deterministic simulations relying on floats - the idea to use floats for money boggles my mind. Having a simple addition give the exact same thing on different machines - bit for bit - is already causing headaches.
  - mikeash 10y ago
    That's odd. IEEE 754 requires that basic operations produce the closest possible result to the exact answer. (Those operations are simple arithmetic, square roots, remainders, rounding, and various format conversions.) As long as the rounding mode is the same on all machines, they should all give identical results for something like addition unless you're using hardware that doesn't do IEEE 754. You will, of course, run into huge trouble if you perform more complex operations. All bets are off once you start doing things like trigonometry or logarithms, unless you implement it yourself.
    - Kenji 10y ago
      Even if you only have 2 additions in a row, the following things cause problems: Rounding mode, distributivity (or rather, lack thereof), intermediate precision, compiler optimisation, denormals, real IEEE754 conformity of the platform... The list goes on.
    - rwallace 10y ago
Animats 10y ago
All I get from that site, with some ad blocking on Firefox 51, is: 11:34:40.979 SecurityError: The operation is insecure. 1 frontend.fe083880.js:15 e.exports<.initialize https://hackerone.com/assets/frontend.fe083880.js:15:31757 t.Model https://hackerone.com/assets/vendor.b247925b.js:31:4648 e.exports<.constructor https://hackerone.com/assets/frontend.fe083880.js:2:20109 q/r< https://hackerone.com/assets/vendor.b247925b.js:31:22455 <anonymous> https://hackerone.com/assets/frontend.fe083880.js:19:31012 t https://hackerone.com/assets/vendor.b247925b.js:1:96 n https://hackerone.com/assets/frontend.fe083880.js:26:14283 forEach self-hosted <anonymous> https://hackerone.com/assets/frontend.fe083880.js:96:23586 t https://hackerone.com/assets/vendor.b247925b.js:1:96 window.webpackJsonp https://hackerone.com/assets/vendor.b247925b.js:1:418 <anonymous> https://hackerone.com/assets/frontend.fe083880.js:1:1 Fail, Hacker One.
xyzzy4 10y ago
Isn't this the same as the premise of the movie Office Space?
- teddyh 10y ago
  To quote from that movie: “Yeah, they did it in Superman III.”
- hexane360 10y ago
  And then a rounding error in the software to exploit the rounding error ends up almost getting them caught.
magma17 10y ago
It requires 3*10^8 transactions to get the amount of the bounty. Good deal.
- pavel_lishin 10y ago
  It's a good thing nobody has access to machines that can rapidly perform repetitive tasks.
  - magma17 10y ago
    Maybe people at NASA.
    - danbruc 10y ago
      Maybe people at NSA. FTFY
STRML 10y ago
Disclosure: I'm CTO of BitMEX, a Bitcoin derivatives exchange built on kdb+/q. We don't compete directly with itBit or any of the exchanges I mention below (we don't do spot trading, they don't do derivatives) but we are in a similar space. Audits matter. Your books should always sum zero. Time and time again, we've seen bugs like this across the space: there was the infamous Bitcoinica "infinite leverage" bug [1], a rounding error in another's order sizes, and it's theorized that a similar bug was leveraged in the downfall of MtGox to create virtually infinite balances and use it to buy Bitcoin up to $1000 in 2013. Whether it's in your engine or outside of it, whether it's a Bitcoin product or any other financial product, make sure there is something - somewhere - that is regularly summing up all accounts and ensuring that every cent or satoshi is accounted for. We run such a system at every execution. If the system doesn't sum zero, we shut down. It's happened three times in two and a half years, each time due to tiny mathematical errors in our liquidation process, each time for less than 10,000 satoshis (~$0.10). We sleep much better at night knowing it's there. Audits would catch the error caused by float math. And of course, don't do float math. 1. I can't find the original reference to it, but it was originally possible to simply edit the DOM to submit any leverage amount you pleased (such as 100,000x; never trust the client!) and then run your account massively into profit - or bankruptcy.
- deleted 10y ago
  [deleted]
- hudon 10y ago
  That's definitely great to have. Or once the system gets too big and it becomes infeasible to sum all accounts, you can also just make sure that you will never create a transaction where the entries within it do not sum to 0 (and make sure your entries are either all written or none).
- deleted 10y ago
  [deleted]
- SomeStupidPoint 10y ago
  Why would you ever use floats for finance? That's like the industry that epitomizes the usecase for fixed point!
tyingq 10y ago
Reminds me of the penny shaving plot in Office Space. https://www.youtube.com/watch?v=6pX3OcPAHR8 https://www.youtube.com/watch?v=6pX3OcPAHR8
kchoudhu 10y ago
I don't understand how you can run a financial exchange and not have break analysis running periodically (if not every transaction). How else are you going to catch mininteractions between complex systems on an on going basis? Apparently Fintech startups have no need for the wisdom built up over the course of 500 years of modern banking, because this stuff is Banking 101 for any engineer at a bank.

70 points by waffle_ss 10y ago

Sounds like someone used floating point to store currency. Bad idea, unless it's part of a macroeconomics model or something.

AtheistOfFail 10y ago
This is why when doing currency, you store in the lowest denomination possible and use whole number (if doing dollars, store cents in integers)
- mikeash 10y ago
  Exactly. (And yes, it's good to point out the right way, not just the wrong way!) I've heard of some applications using tenths of a cent since they needed more precision. For Bitcoin applications, I think you'd want to work in integer satoshis.
  - Declanomous 10y ago
    The default currency type I've seen used for accounting is a decimal with 4 digits trailing the decimal. I forget the leading digits, but it is something like 14. Basically I think the idea with 4 digits after the decimal is that the smallest denomination you can have is 1 penny, and that allows you to calculate percentages of pennies accurately to a hundredth of a percentage point.
  - andrepd 10y ago
    What if you have to calculate, say, a 0.5% fee on a few satoshis?
    - AtheistOfFail 10y ago
      Calculate it and round it off after calculation to the nearest satoshi.
- danbruc 10y ago
  That does not solve the problem in general, you still may end up with fractional quantities if you, for example, calculate a 1% fee. The correct way to do it is to use a decimal floating point format AND carefully pay attention to rounding. Also note the the way you round usually depends on the context, for some calculations you want to round up, for some down, and for some in yet another way. So you perform explicit rounding with an explicit rounding mode everywhere it is required and don't assume that implicit rounding or the default rounding mode will do the right thing because they won't in general. EDIT: To expand a bit on the context. If you, for example, charge a percentage fee you can choose between rounding up getting at least the fee you are asking for or rounding down not charging the customer more than you are asking for. Or you can try to be less biased and round either up or down depending on the fractional part. This may still require tie-breaking, either in a direction of your choice, or randomized, or by some rule like round half to even. Different choices will obviously have different biases. While this may almost seem somewhat pedantic, such things have been exploited, see for example »Computer Capers: Tales of Electronic Thievery, Embezzlement & Fraud«. [1][2] Also note that there may be even legal regulations prescribing how you can and can not round, for example between the Euro and the replaced national currencies. [3] I also have some faint memories of a case against someone systematically exploiting rounding errors but I can not come up with a reference and may even misremember this. [1] http://www.snopes.com/business/bank/salami.asp http://www.snopes.com/business/bank/salami.asp [2] https://www.amazon.com/Computer-Capers-Electronic-Thievery-Embezzlement/dp/069001743X https://www.amazon.com/Computer-Capers-Electronic-Thievery-E... [3] http://www.sysmod.com/eurofaq.htm#ROUNDING http://www.sysmod.com/eurofaq.htm#ROUNDING
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - mikeash 10y ago
    Won't decimal floats still result in errors like this if the absolute value gets too large? You can avoid that by ensuring that the mantissa has enough digits to hold the largest value you'll ever encounter with enough significance to represent the smallest value you'll ever encounter, but at that point you might as well use an integer with that smallest value as the unit.
- SolarNet 10y ago
  Or use a language with arbitrary precision numbers (they are only like 50 years old so I can see why many people don't use them /s). As someone else already pointed out, this still prevents calculations of fees as a percentage, and other issues.
  - waqf 10y ago
    C'mon, the Egyptians had arbitrary precision numbers.
  - mikeash 10y ago
    Don't you still have to be smart about rounding at some point? Otherwise compounding a (say) 1% fee will lead to arbitrarily long numbers.
    - SolarNet 10y ago
      Yes. But then you write that at the boundary. Along with the other consistency checks. And you are forced to think about it at the appropriate time, instead of forgetting about it entirely (floats) or introducing subtle errors (integers, and then likely casting it to a float to calculate 1% and then adding it back by casting back to an integer; hint: that's also a bad idea because it has floats in it - which as we've learned recently on HN - are not that deterministic or precise).
      - mikeash 10y ago
        Let's say you're not a complete idiot and avoid the use of floats altogether, what subtle errors would you avoid by using arbitrary precision numbers over integers?
        SolarNet 10y ago
        Well first riddle me this. How do you calculate a ⅓% (1 / 3 of a percent) fee with integers. Depending on your choice of solution I can tell you how it has a problem and how arbitrary precision numbers would solve it.
- sp332 10y ago
  I think banks keep track of calculations (like interest) down to the 4th decimal place, 1/10,000 of a penny. Then they round to the nearest cent when settling.
- cwmma 10y ago
  the lowest denomination of the dollar is the mill not the cent.
- spc476 10y ago
  There are still items in the US that use mills (1/1000 of a dollar). Two examples: property tax and gas.

koolba 10y ago

Those that do not understand why floating point math has no place in the world of money are doomed to repeat this mistake. Over and over and over ... The snippet of what I presume is their API response is interesting: {"currencyCode":"XBT","balance":100000.00000008,"available":100000.00000008,"onDeposit":0} The amount fields are JSON numbers. That's fine for integers up to 2^52[1] but can have issues with floating point math. They'd be better off representing everything as satoshis and doing integer math on everything. I bet their entire system is based on floating point math. Tisk tisk ... [1]: Yes probably not an issue unless your Bill Gates and convert your networth to Zimbabwean dollars...

Kenji 10y ago
As someone who is trying to get deterministic simulations relying on floats - the idea to use floats for money boggles my mind. Having a simple addition give the exact same thing on different machines - bit for bit - is already causing headaches.
- mikeash 10y ago
  That's odd. IEEE 754 requires that basic operations produce the closest possible result to the exact answer. (Those operations are simple arithmetic, square roots, remainders, rounding, and various format conversions.) As long as the rounding mode is the same on all machines, they should all give identical results for something like addition unless you're using hardware that doesn't do IEEE 754. You will, of course, run into huge trouble if you perform more complex operations. All bets are off once you start doing things like trigonometry or logarithms, unless you implement it yourself.
  - Kenji 10y ago
    Even if you only have 2 additions in a row, the following things cause problems: Rounding mode, distributivity (or rather, lack thereof), intermediate precision, compiler optimisation, denormals, real IEEE754 conformity of the platform... The list goes on.
  - rwallace 10y ago

Animats 10y ago

All I get from that site, with some ad blocking on Firefox 51, is: 11:34:40.979 SecurityError: The operation is insecure. 1 frontend.fe083880.js:15 e.exports<.initialize https://hackerone.com/assets/frontend.fe083880.js:15:31757 t.Model https://hackerone.com/assets/vendor.b247925b.js:31:4648 e.exports<.constructor https://hackerone.com/assets/frontend.fe083880.js:2:20109 q/r< https://hackerone.com/assets/vendor.b247925b.js:31:22455 <anonymous> https://hackerone.com/assets/frontend.fe083880.js:19:31012 t https://hackerone.com/assets/vendor.b247925b.js:1:96 n https://hackerone.com/assets/frontend.fe083880.js:26:14283 forEach self-hosted <anonymous> https://hackerone.com/assets/frontend.fe083880.js:96:23586 t https://hackerone.com/assets/vendor.b247925b.js:1:96 window.webpackJsonp https://hackerone.com/assets/vendor.b247925b.js:1:418 <anonymous> https://hackerone.com/assets/frontend.fe083880.js:1:1 Fail, Hacker One.

xyzzy4 10y ago

Isn't this the same as the premise of the movie Office Space?

teddyh 10y ago
To quote from that movie: “Yeah, they did it in Superman III.”
hexane360 10y ago
And then a rounding error in the software to exploit the rounding error ends up almost getting them caught.

magma17 10y ago

It requires 3*10^8 transactions to get the amount of the bounty. Good deal.

pavel_lishin 10y ago
It's a good thing nobody has access to machines that can rapidly perform repetitive tasks.
- magma17 10y ago
  Maybe people at NASA.
  - danbruc 10y ago
    Maybe people at NSA. FTFY

STRML 10y ago

Disclosure: I'm CTO of BitMEX, a Bitcoin derivatives exchange built on kdb+/q. We don't compete directly with itBit or any of the exchanges I mention below (we don't do spot trading, they don't do derivatives) but we are in a similar space. Audits matter. Your books should always sum zero. Time and time again, we've seen bugs like this across the space: there was the infamous Bitcoinica "infinite leverage" bug [1], a rounding error in another's order sizes, and it's theorized that a similar bug was leveraged in the downfall of MtGox to create virtually infinite balances and use it to buy Bitcoin up to $1000 in 2013. Whether it's in your engine or outside of it, whether it's a Bitcoin product or any other financial product, make sure there is something - somewhere - that is regularly summing up all accounts and ensuring that every cent or satoshi is accounted for. We run such a system at every execution. If the system doesn't sum zero, we shut down. It's happened three times in two and a half years, each time due to tiny mathematical errors in our liquidation process, each time for less than 10,000 satoshis (~$0.10). We sleep much better at night knowing it's there. Audits would catch the error caused by float math. And of course, don't do float math. 1. I can't find the original reference to it, but it was originally possible to simply edit the DOM to submit any leverage amount you pleased (such as 100,000x; never trust the client!) and then run your account massively into profit - or bankruptcy.

deleted 10y ago
[deleted]
hudon 10y ago
That's definitely great to have. Or once the system gets too big and it becomes infeasible to sum all accounts, you can also just make sure that you will never create a transaction where the entries within it do not sum to 0 (and make sure your entries are either all written or none).
deleted 10y ago
[deleted]
SomeStupidPoint 10y ago
Why would you ever use floats for finance? That's like the industry that epitomizes the usecase for fixed point!

tyingq 10y ago

Reminds me of the penny shaving plot in Office Space. https://www.youtube.com/watch?v=6pX3OcPAHR8 https://www.youtube.com/watch?v=6pX3OcPAHR8

kchoudhu 10y ago

I don't understand how you can run a financial exchange and not have break analysis running periodically (if not every transaction). How else are you going to catch mininteractions between complex systems on an on going basis? Apparently Fintech startups have no need for the wisdom built up over the course of 500 years of modern banking, because this stuff is Banking 101 for any engineer at a bank.