3 ms·

is it alarming at all that the # of redeemable bitcoins are provenly monotonically decreasing after some period of time? I guess if there is a lower limit it

is it alarming at all that the # of redeemable bitcoins are provenly monotonically decreasing after some period of time? I guess if there is a lower limit it shouldn't matter?

wyager 13y ago
It's not really that alarming. It has some deflationary effects (which Bitcoin was designed with anyway). Worst case, let's say all Bitcoins except .00000001 (1 Satoshi) have been destroyed. Well, no problem, we just make the base unit .00000000000000000001 Bitcoin or something. As far as I know, the only reason 21,000,000*100,000,000 units was chosen was to fit comfortably in the 52-bit mantissa of a 64-bit IEEE 754 floating point number. Edit: Apparently I just made that up... But it makes sense! Edit 2: Apparently some other devs believe this is the case as well.
- davidw 13y ago
  Do people often use floats in their bitcoin code?
- bunderbunder 13y ago
  BTC use fixed-point math with 64-bit unsigned integers. Precision is 8 decimal places. So at least as currently built, I believe 1 Satoshi is the smallest possible unit of Bitcoin. There's talk about it being possible to move the decimal point with a protocol update, but I'm not sure about how the logistics of that would work, or just how far it's possible to move it.
  - Nilzor 13y ago
    How can a protocol dealing with currency invented after year 2000 have limits on the number of decimals or its positionn?
    - nfoz 13y ago
      I'll hazard a guess: the protocol might not want to allow arbitrarily large transaction messages. Could introduce points of failure / DOS'ing.
    - bnr 13y ago
      I have 1 bitcoin. I send you 2^-32 btc. How much do I have left?
    - bunderbunder 13y ago
      In a nutshell, because sometimes the point really does not (and should not) float. The main reason for choosing variable-precision numbers for general-purpose computing is that they have a very wide dynamic range that can adjust automatically, which makes them easier to use in more situations. In financial applications, that advantage doesn't really apply; banks don't often encounter situations where customers are worried about a ten thousandth of a cent, and they never encounter situations where it's suddenly OK to only track a transaction with dollar-level precision. Meanwhile there are some risks to using arbitrary-precision math too. If BTC used floats, then that might result in it being vulnerable to attacks that are able to take advantage of rounding errors in floating-point math. If BTC used infinite-precision decimals, then that might result in it being vulnerable to attacks that work by creating ridiculously high-precision numbers that implementations have a hard time dealing with.
  - wyager 13y ago
    The idea would have been to allow BTC software to be written in languages that only have float support (like JS). The Bitcoin code itself actually frequently uses decimal64 as well as uint64_t.

is it alarming at all that the # of redeemable bitcoins are provenly monotonically decreasing after some period of time? I guess if there is a lower limit it shouldn't matter?

wyager 13y ago

It's not really that alarming. It has some deflationary effects (which Bitcoin was designed with anyway). Worst case, let's say all Bitcoins except .00000001 (1 Satoshi) have been destroyed. Well, no problem, we just make the base unit .00000000000000000001 Bitcoin or something. As far as I know, the only reason 21,000,000*100,000,000 units was chosen was to fit comfortably in the 52-bit mantissa of a 64-bit IEEE 754 floating point number. Edit: Apparently I just made that up... But it makes sense! Edit 2: Apparently some other devs believe this is the case as well.

davidw 13y ago
Do people often use floats in their bitcoin code?
bunderbunder 13y ago
BTC use fixed-point math with 64-bit unsigned integers. Precision is 8 decimal places. So at least as currently built, I believe 1 Satoshi is the smallest possible unit of Bitcoin. There's talk about it being possible to move the decimal point with a protocol update, but I'm not sure about how the logistics of that would work, or just how far it's possible to move it.
- Nilzor 13y ago
  How can a protocol dealing with currency invented after year 2000 have limits on the number of decimals or its positionn?
  - nfoz 13y ago
    I'll hazard a guess: the protocol might not want to allow arbitrarily large transaction messages. Could introduce points of failure / DOS'ing.
  - bnr 13y ago
    I have 1 bitcoin. I send you 2^-32 btc. How much do I have left?
  - bunderbunder 13y ago
    In a nutshell, because sometimes the point really does not (and should not) float. The main reason for choosing variable-precision numbers for general-purpose computing is that they have a very wide dynamic range that can adjust automatically, which makes them easier to use in more situations. In financial applications, that advantage doesn't really apply; banks don't often encounter situations where customers are worried about a ten thousandth of a cent, and they never encounter situations where it's suddenly OK to only track a transaction with dollar-level precision. Meanwhile there are some risks to using arbitrary-precision math too. If BTC used floats, then that might result in it being vulnerable to attacks that are able to take advantage of rounding errors in floating-point math. If BTC used infinite-precision decimals, then that might result in it being vulnerable to attacks that work by creating ridiculously high-precision numbers that implementations have a hard time dealing with.
- wyager 13y ago
  The idea would have been to allow BTC software to be written in languages that only have float support (like JS). The Bitcoin code itself actually frequently uses decimal64 as well as uint64_t.