Integer or float used in Bitcoin?

[NeoCortX]

What data type is used in Bitcoin to store the value of a transaction?

I doubt it's double or float due to rounding errors. My guess is that it's integer or long with a system for moving the decimal. Can someone help explain this?

I tried Google, but it said just "I don't know".

Thanks.

[pc]

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

[Stephen Gornick]

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

The Bitcoin.org client will display the number according to the value of the units setting (i.e.,. BTC, mBTC, or uBTC).

For instance;

Here's the raw data for a transaction:
 - http://blockchain.info/rawtx/97990146ef27291626518b39b0217caa38276d5ed16306ef233d90d0c1414924

The inputs are:
 "value":5103074576    <--   51.03074576 BTC
 "value":4882066520    <---  48.82066520 BTC

There is just one output, and the value of it is:
 "value":9985141096    <--   99.85141096 BTC

[DannyHamilton]

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

Which is why the "Satoshi" is currently the smallest unit of value that can be used in a transaction.

This is also why statements suggesting "infinitely divisible", and "we can just add more decimals" would not be quite as simple to implement as some people believe.  If it becomes necessary to do so, then it is possible, just not as easy to do as it is to say.

[TalkingAntColony]

What would it take to update the protocol to, say, a 128-bit integer?

[DannyHamilton]

What would it take to update the protocol to, say, a 128-bit integer?

If you are suggesting that as a way to increase the number of decimal places a bitcoin can be split into, then it would take more than increasing the number of bits in the integer, you'd also have to multiply all values in the blockchain by some multiple of 10 to increase the number of digits in the values.  This would be a "hard fork", meaning that anybody who didn't upgrade, would continue to operate on the old system, and anybody who did upgrade would be operating on the new system.  This creates essentially two incompatible cryptocurrencies each calling themselves "bitcoin".

[grue]

I tried Google, but it said just "I don't know".

no you didn't
https://bitcointalk.org/index.php?topic=13837

[gmaxwell]

This creates essentially two incompatible cryptocurrencies each calling themselves "bitcoin".

Assuming that there is anyone using the old one— the way you'd actually do this change is that you'd write it, validate it, test it.. and then agree that it would become active as of block  now+16 years (or whatever).  Then everyone has 16 years to update, and after than new blocks are interpreted the new way.

This sort of thing could be done for changes which are clearly necessary and uncontroversial— and I'd guess a precision increase would fit that bill if bitcoin ever deflated to the point where it seemed like it would eventually be an issue—, but it's not generally viable otherwise.

[DannyHamilton]

This creates essentially two incompatible cryptocurrencies each calling themselves "bitcoin".

Assuming that there is anyone using the old one— the way you'd actually do this change is that you'd write it, validate it, test it.. and then agree that it would become active as of block  now+16 years (or whatever).  Then everyone has 16 years to update, and after than new blocks are interpreted the new way.

This sort of thing could be done for changes which are clearly necessary and uncontroversial— and I'd guess a precision increase would fit that bill if bitcoin ever deflated to the point where it seemed like it would eventually be an issue—, but it's not generally viable otherwise.

Agreed.  That would be why I originally stated:

. . . statements suggesting "infinitely divisible", and "we can just add more decimals" would not be quite as simple to implement as some people believe.  If it becomes necessary to do so, then it is possible, just not as easy to do as it is to say.

[2_Thumbs_Up]

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

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?

[kjj]

What would it take to update the protocol to, say, a 128-bit integer?

It wouldn't need to be done that way. Not all of the 64 bits are used at the moment, so one of the spare bits could be used to indicate that the value is to be scaled. So technically it's straightforward, but as others have explained it's a "hard fork", so the change would need to be broadly aged well in advance of it's implementation.

The change may never be needed anyway, as some kind of sub-ledger may become popular for handling small payments.

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.

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

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?

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.

[prezbo]

What would it take to update the protocol to, say, a 128-bit integer?

It wouldn't need to be done that way. Not all of the 64 bits are used at the moment, so one of the spare bits could be used to indicate that the value is to be scaled. So technically it's straightforward, but as others have explained it's a "hard fork", so the change would need to be broadly aged well in advance of it's implementation.

The change may never be needed anyway, as some kind of sub-ledger may become popular for handling small payments.

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.

Values in bitcoind are 64-bit integers, with a convention that "a bitcoin" means put the decimal point 8 places from the right.

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?

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.

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.

[maaku]

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.

[casascius]

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.

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.)

[maaku]

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.

[2112]

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.

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.

[maaku]

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.

[2112]

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.

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 .

[DeathAndTaxes]

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.

[prezbo]

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.

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