Its already designed around floating point, but being used in its fixed-point capacity. To keep the same overall design, you would need to move to 128-bit floating point numbers, which would be moving from a 52-bit to a 112-bit significand. 21E14 fits in a 51 bit number, and it was intentionally chosen to leave an extra bit to avoid sum calculation bugs, so that leaves us with 111 bits. So whatever decimal multiple fits within 111 bits would be the new count of base-units, which could arguably be called "new sats". That number is about 2.596E33, or 21E32, which increases the number of "new sats" from 1E8/BTC to 1E26/BTC. That fractionalizes the "old sat" by 18 zeros, which moves the "new sat" as one atto-sat, or one thousandth of a femto-sat.
Login to reply
Replies (5)
By the way, a 128-bit floating point number is called a "double double" in C, and a "quadruple" in other languages.
Now I feel dumb at math. Great post.
Oof great post man. May be used in a BIP one day in a hundred years if we ever need it. I'm not sure we will though. Supply is fine. We can arbitrarily divide on any L2.
I was wrong about "double double" in C, that is only a 107 bit significant" which is different than an IEEE 754 quadruple. So when you get into 128-but floating point numbers, you will run into divergent primitives across languages, which is a liability that is not present in the "safer" 64-bit floating point.
The math behind bitcoin and its architectural decisions are fairly straightforward if you understand binary arithmetic. Of course that's easy for me to say as an IC designer.