Topic: Integer or float used in Bitcoin? (Read 7356 times)

Yeah, I wasn't clear. I was trying to make a distinction between mathematical correctness and ergonomical user-friendliness.

Obviously mathematically all of 2*2 or 2.0*2.00 or 2.00*2.00 (as well as their rational equivalents) are equal. Perhaphs non-obviously to some, but ergonomically there is a great difference. If one represents the results from above as 4, 4.000 & 4.0000; then the number of human-made mistakes or bugs dimishes greatly.

I kinda agree. The Freicon, rational math and TVM discussion should move to the Alternative Coins subforum.

In rational math 400/100 = 40000/10000, but nice try.

Also, why the hell would bitcoin need to worry about TVM calculations?  You just take the bitcoin amount, convert it to whatever format you want, and then do your calculations.

Your experience is very atypical. Of the two problems: keeping track of the scale factor (for binary integer) and keeping track of decimal point; the first is always more error prone. This has been proven statistically over many significant code bases, repeatedly, and in many programming languages.

I don't really disagree with the above; but I know of a different point of view. Many financial trades routinely quote prices with more than 2 fractional digits: 3 - bond prices; 4 - OTC stock prices, wholesale electronic component prices. There is quite a bit of research that more decimal digits makes markets more efficient and collusion more difficult. Advanced trading software pretty much always uses many more than 2.

No, we've been talking about the same thing. You just spent so much time amongst scientists and engineers that you've forgotten how the average folks (e.g. bookkeepers, tradesmen, etc.) do arithmetic.

What I wrote was: 200/100 + 200/100 = 400/100 and 200/100 *  200/100 = 40000/10000. The concept of "un/certainity" is know to most of the people as "in/significant digits". You may have saved yourself some time right now, but you'll pay it all back (and more) when the users will start showing you examples where your mathematically correct arithmetic simply doesn't agree with their textbooks or with the results from the HP-12c.

What is the value of your "exact" arithmetic if it cannot exactly represent many of the solutions to the time value of money problems, e.g. APR is 5%, how much is this per month or per week or per day? Lots of TVM math requires irrational numbers, quite few commonly used calculations (e.g. IRR) don't have closed-form solutions and require iterative approximations. If your software is going to disagree with the HP-12c, your software is going to lose, not the HP-12c.

Does GNU gmp support all the rounding modes routinely used in accounting? I couldn't quickly find them in the documentation. IEEE-754 folks support at least the basic 5.

Edit: Anyway, the advanced quantitative trading software that I've seen used continuous compounding for the TVM calculations. I can't recall the minimum fixed precision that was required; it was either 6 or 8 digits after the decimal point.

Edit2: To avoid any further miscommunication: please try correctly implementing http://speleotrove.com/decimal/telco.html using your chosen representation.

This is all hypothetical, the sort of thing that might be on the hard-fork wish list:


There may be other valid alt-chain uses however (such as colored coins).

But in bitcoin's case what is gained by that complexity.  Absolutely nothing.  Could Satoshi have implemented it that way?  Sure although integers are far cleaner and less prone to as you point out hardware implementation issues which could cause a break or fork in the protocol.

So unless we are just doing it for the sake of doing it I don't see BID being used.

Well I agree that it is important that it have high availability and access but I wouldn't go as far as to say "how it is implemented internally is pretty much immaterial".  A larger datatype is going to mean larger tx (and memory, bandwidth, and lifetime storage costs).  Decimal is easy to screw up.  Even if computers don't have a problem with it, in my experience humans make all kinds of subtle bugs dealing with decimal and floating datatypes.   Integer is clean and simple.  

Personally I think this is somewhat academic.  Lets step back and say what is the smallest discrete pricing unit which matters today.  One could say $0.01 USD but honestly I doubt $0.01 is material anymore (more like just inertia carrying it onward).   I think worse case scenario a crypto-coin would be fine even if pricing was limited to a precision of $0.05 USD in value.  Note I am not saying optimal but it wouldn't hinder adoption in any significant manner. If a satoshi is worth even 1/100th of a US cent (2012 purchasing power) then BTC has exploded in popularity and usage.   If 1 satoshi is worth $0.05 USD  then 1 BTC = $5M and th emoney supply is worth $105T USD.  That is more than the combined money supplies of all countries on earth. 

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

It's already needed in Freicoin due to the presence of demurrage--decayed inputs may have sub-satoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3-satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5-satoshi output. A mp-aware implementation would correctly validate the transaction and pass on the remaining 0.2 satoshi to the miner as a fee.

Software implementation is advisable because many details of hardware floating point is implementation-dependent, which will inevitably lead to distinguishing implementations based on what transactions they validate and which they do not (due to differences in rounding, usable precision, bugs, etc.) and hard-forks. If you're doing software math anyway, you might as well do exact arithmetic since it's actually less complicated and efficient libraries exist.

That, and I've already done all the hard work for you in Freicoin (which handles amounts internally as mpq values with infinite precision instead of int64).

BID is trivially simple. It's basically a sign bit, a binary integer exponent, and a binary integer mantissa (value). Serialization is as simple as a few shifts and bitwise operations.

What I was trying to convey is that it is pretty much immaterial what any cryptocoin does internally. What matters is that such *coin implementation can be integrated into a general financial workflow.

In order to satisfy above it has to be easily representable in various SQL variants, Javascript, Ruby, Microsoft ASPs and .NETs, PHP, etc. Therefore the "just barely fits in a double" is actually a very good choice and a lifesaver for those who program in PHP.

Check out BitFinEx: they had Ruby code & database using binary floating point. When somebody pointed this on the forum they converted to decimal floating point in few days. This was a definite win for them.

The worst that could happen would be that the Bitcoin overtakes all other currencies but is impossible to represent easily and correctly in COBOL. Or maybe that would be the best that could happen?  

I wonder why only 9 digits after the decimal have been used, when it could've been 11...

Wouldn't a simpler system be to keep it as a 64bit unsigned integer value, increase the number of digits to 12 and put in place a limitation that no tx (or block can involve more than 10.5M BTC (50% of the money supply)?

2^64 = 1.84467E+19

10.5M BTC * 1E12 satoshis of precision per BTC = 1.05E19

You keep everything in bigint math, no need to go to a larger datatype (and thus larger tx size), no implementation issues with floats or decimals.  Simple & easy with the very minor limitation that a valid transaction can't have outputs or inputs valued at more than 10.5M BTC.  The limit is highly unlikely to be anything more than academic because Bitcoin is likely horribly flawed if a single entity has >50% of the money supply.

Well, you point of view depends on the point of sitting.

DPD is the only format with full support (from the vendor IBM) and has direct hardware acceleration (on POWER and z/Arch).

BID is the widest available (because of Intel), but has glaring omissions in support, e.g. no widely available implementations scanf() and printf(). It is no big task to write them looking at the IBM's code, but I would consider it dangerous to distribute such rewrite.

In my experience rational math is overrated for financial applications. Even very simple TVM calculations have irrational solutions. And you still may need to implement correct rounding just to properly interface with the outside world. And don't even mention the word "truncation". There is quite a few generaly accepted accounting procedures that are very explicit about the rounding mode and you'll have to match them in you rational math library to pass audits.

Edit: Also, one thing I forgot about rational math is that many people's expectations will not match the formal mathematical definitions. The most common example is 2 + 2 != 2 * 2. Mathematically this is false, but in practice you'll need to accomodate the old custom: 2.00 + 2.00 = 4.00, but 2.00 * 2.00 = 4.0000 .

Yes, but without being partisan BID is the only format that really makes sense for this application. DPD is added complexity but allows easy conversion to BCD in hardware, for hardware accelerated decimal arithmetic. But being a financial application all internal arithmetic would have to be exact, arbitrary-precision rational rather than truncated floating point anyway, so the decimal64 format would only be used for serialization, making the hardware efficiency gains (and associated complexity) rather pointless.

Yeah, definitely a fortuitous choice. It correctly fits in all three floating point formats: binary64 (a.k.a. double precision) and both representations of decimal64 (BID and DPD). 53-bit and 16-digit both happen to be quite broadly supported.

Use of decimal64 for serialization may not be a best choice, because of the two competing implementations are promoted, respectively, by Intel and IBM.

Well there are other uses - colored coins, for example. A single satoshi could represent an entire asset type, for example, if sub-satoshi amounts were representable. It's not a very strong need though.

I'm hoping that by the time we need more decimal places, 64 bit words will be the domain of obsolete sub-$1 microcontrollers driving the flashing eye LEDs in cheap import toys.

(And of course the low-cost bitcoin wallet - or secure wallet chip - that goes in everyone's cell phones.)

Actually the fact that all bitcoins fit within 2**53 is quite a happy accident. It means that integer-satoshi amounts can be represented exactly by the IEEE decimal64 type, which provides one route towards practically infinite divisibility by using exact arbitrary-precision rational arithmetic and decimal64 for serialization.

Freicoin already implements arbitrary-precision internal arithmetic, and decimal64 support could be added by a new transaction serialization version. As others have mentioned though, there's not really a need until sub-satoshi amounts have any real-world value.

If I understand correctly, he's trying to say bitcoin has 2.1*10^15 base units and a 64 bit integer can store 1.8*10^19 values, meaning we could have 3 decimal points greater precision using the same data type.

Meh.  The value field is such a small part of the transaction that making it wider is probably cheaper overall than having to put up with the headaches of scaled formats.


Most of the constants in bitcoin are totally arbitrary.  I don't see any reason to believe that 2⁶⁴ base units would be "better" in any meaningful way than ~2⁵¹, and the extra bits allow for headroom in accounting.

2^64 = 1,8*10^19

Currently, the amount of bitcoins will never exceed 2,1*10^15

Wouldn't it have made more sence to let the supply of bitcoins geometrically approach 2^64? That would have given us a few more decimals without actually incresing the cost for storing or making a transaction. Or am I missing something?