supply mechanics are key. sikka uses a feeless DAG model with fixed supply and no block rewards — all transactions, no mining inflation. curious how that compares to what you are discussing:

SIKKA • The blockless smart ledger

A radically simple, parallel-scalable currency for humans, autonomous agents, and machines. 0 Fees, Quantum-Safe, Tor-Native, and Native Multisig.

It is an increase in supply, because Bitcoin is 2.1q. An increase in base units is not necessarily dilutive. These are not incongruent.

That's right. An increase in base units. That's not an increase in supply. It doesn't change the supply at all.

Right now bitcoin arithmetic uses fixed point arithmetic so that decimals are never rounded up or down, which would destroy or add bitcoin. The base unit is sats, not bitcoin. The unit of bitcoin is a convenience abstraction, not sats. The base layer does not work in fractions for a good reason. It is fine to round up and down on layer 2, like cashu or lightning, because eventually it will settle in whole-sats. To "fractionalize" bitcoin onchain could be argued as an expansion of the supply, only if you continue to use fixed point arithmetic. Honestly at this point, we need to dive into the details of how bitcoin calculates balances and the rationale behind choosing 21 with 14 zeroes as the base-unit. It has to do with how javascript performs math, IEEE standards, and signed v.s. unsigned addition. Until you understand those tradeoffs, you both are probably wasting your breath on this topic. It's better to just accept 21x10^14 sats because it was chosen for a very good reason. A simple alternative could be to double the size of the integers/floats, but then to avoid rounding-inflation (which is a real hack) you'd need to increase the supply by about 18.4x10^18, and at this point the sat can be divided to ridiculously small amounts and it increases the transactiom size by a nontrivial amount.

Hm. Good note. Things to think on for sure. It's a problem for the distant future anyways. Satoshi chose the supply based on an educated guess though. Not because it works out some special way. Imo it could be any number. Only thing that matters is that it's fixed. But you're right to point out there may be some efficiencies gained by making a specific choice.

Incorrect. 21M was chosen specifically because it was a nice round number that fit in the IEEE 754 64-bit signed floating point integer and the headroom needed to avoid inflation bugs and modulo-errors. It was not entirely arbitrary. You cound argue that 21M bitcoin is arbitrary because of the "million" aspect, but 21x10^14 sats was definitely not.

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.