I see. I see what you mean. Well then how many we need to add? Like 4 more decimal places? Good starting point of discussion. Sats is not in the protocol either fwiw. 😂 This is why they argue to just call them all bitcoins and drop the decimal place. I think the whitepaper explains 21 million as the supply. At the protocol level, there is no 21 million to @Justin (shocknet) ⚡ credit. Also to his credit, it probably would be a hard fork to do that. I think we could add a floating point with a soft fork but that's a lot harder than just adding a 0. We don't have to get rid of sats as the base unit for a long time though. Maybe never but it's going to depend on L1 and L2

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.

By the way, a 128-bit floating point number is called a "double double" in C, and a "quadruple" in other languages.

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.