Mankind needs fractional satoshis
Bitcoin Cash aims at becoming the world currency. As discussed previously, terabyte blocks are needed to achieve this goal. However, the Bitcoin Cash protocol also needs a few changes as well. In this post, I will demonstrate why fractional satoshis are needed for Bitcoin Cash.
In the following, for the sake of concision, Bitcoin always refers to Bitcoin Cash.
Overview of the issue
A satoshi is, presently, the smallest unit of payment that can be sent across the Bitcoin network. There are 100 million satoshis in 1 bitcoin. In particular, the smallest non-zero transaction fee that can be paid is 1 satoshi. Non-zero transaction fees are desirable in order to eliminate spam; however, the original intent behind Bitcoin is clearly to keep those fees vanishingly small as far humans are concerned.
At mankind scale, let’s assume that we have 10 billion humans, and that every human wants to do 50 transactions a day. This might seem a bit high - after all, mankind won’t reach 10 billion humans before 2050, however, good engineering implies safety margins and thinking ahead. I firmly believe that Bitcoin must be engineered to support 10 billion humans and 50 transactions per day per human.
Let’s further assume that those transactions are secured by paying exactly 1 satoshi per transaction (1). The miners collect 1e10 * 50 * 365 / 1e8 ≈ 1.8 millions BCH per year. This amount is huge, about 10% of the total BCH that will ever be in existence (2).
Bitcoin Cash needs to be designed in such a fashion that it is possible for mankind to spend less than 0.001% of its whole monetary supply per year in order to transact freely. Over the lifetime of a human, 100 years, the total transaction fees would remain below 0.1% her or his average monetary capital, which feels about right.
Practical example: let’s assume that my average monetary capital is 100,000€ (just counting cash, not any other asset classes). Over the course of my 100 year’s lifetime, I will pay 0.1% of this amount to cover all my transaction fees, that is, 100€. On average, it’s 1€/year, that is, 0.27 cents per day. We are not far of the 1/10th of a cent per day of my previous analysis.
As such, the current Bitcoin protocol is not tenable at mankind scale. Satoshis are too large, mankind needs fractional satoshis.
14-bit left shift
The Bitcoin transactions are encoded with 64-bits integers. This choice, made back in 2009, remains sound. For the foreseeable future, all CPUs will be 64-bits CPUs. However, the current Bitcoin implementation is wasteful. There are 14 bits that are wasted, as we will see below. Yet, it turns out that those 14 bits are exactly what Bitcoin needs to make transaction fees low enough at mankind scale.
Proposal: 1 bitcoin is redefined as 1,638,400,000,000 naks - nak being the shorthand of Nakamoto - that is 214 nakamoto per satoshi.
Let’s demonstrate why 14 bits makes sense. With 50 bits, it is possible to represent 250 satoshis, that is, about 11 millions BCH. The richest BCH address in existence contains about 400k BCH. It’s unlikely that this address will ever grow 1M BCH, let alone 11M BCH.
Thus, in order to represent even the richest BCH address, the protocol only needs 50 bits. While it may be theoretically possible to accumulate more than 11M BCH on a single address, it’s straightforward to add a rule in the Bitcoin protocol to invalidate any transaction which would try to accumulate more than 11M BCH on a single address, forcing the owner of such a fortune to split her/his fortune over 2 addresses instead.
Now, the protocol is left with 64-50 = 14 bits which are “wasted” if we want to preserve the encoding of transactions inputs and outputs as 64-bits unsigned integers. Re-encoding all amounts in sat as nak only requires a 14-bit shift to the left.
As 214 = 16384, we can revisit our initial back-of-the-envelop calculations with 10 billion humans doing 50 transactions a day. We have 1e10 * 50 * 365 / (16384 * 1e8) = 111.4 BCH paid in fees to the miners per year. This is much better, about 0.0005% of the whole monetary supply paid to the miner per year, that is, 0.05% over the 100 year lifetime of a human.
A non-urgent yet kind-of-urgent change
Fractional satoshi won’t become a problem until about 1% of mankind starts using Bitcoin to pay for everything. However, every single day that passes, there are more software out there which are dependent on the current instance of the Bitcoin protocol. Thus, the Bitcoin ecosystem is accumulating technical debt.
We know that this debt will have to be paid back. Indeed, as demonstrated above, keeping satoshis as the smallest payment unit is not tenable. We also know that this debt comes with compound interests. At present time, fixing this issue will only incur a modest friction in the ecosystem. 10 years from now, if Bitcoin has any measurable degree of success at being a currency, then, it will be a huge mess. Every single piece of Bitcoin-dependent software will be broken by such a change.
Thus, I call to the Bitcoin developers to coordinate in order to introduce fractional satoshis in their mid-term roadmap.
Pre-emptive answers to questions
Will I still own the same amount of BCH? Yes, there is zero impact on your current BCH holding. If you have 1 BCH now, you will still have exactly 1 BCH after the change.
Does it change the upper limit on the number of BCH? Technically yes, but in practice, no. This change would push back the date when mining becomes purely fee-funded by 4*14=52 years; and the total amount of extra BCH which will ever be mined will be less than 0.001 BCH. Hardly noticeable.
Nitpicking, why not 18 bits?
I do feel strongly that fractional satoshis are needed, and that 14 bits of extra precision is a minimum. However, if someone has a good reason to motivate a shift beyond 14 bits, maybe up to 18 bits, then, this person might be right. The discussion below is merely opinionated. This is not a demonstration.
The richest BCH address hold about 400k BCH. Thus, technically, it is still possible to adjust the protocol to free up to 18 bits, with a hard-cap at 703k BCH for a single BCH address. However, I do see for potential edge cases in the ecosystem of Bitcoin.
If Bitcoin succeeds, then the world will start implementing accounting packages, ERP, POS, CRM …, where assets are valued in Bitcoins, or rather in naks. Most of those software developers will use int64 integers (signed) to track the valuations of those assets. Why? Just because it’s what naturally comes to mind as a developer if you need large signed integers.
As the non-monetary assets are typically valued more than the monetary assets - eg. for most people, their home is worth more than the cash they have at the bank, the same goes for companies - those accounting books may contain values that exceed 10M BCH. Those situations, arguably rare, would trigger bugs known as numeric overflows.
Through a 14-bit shift, naive financial software implementations would still work up to 5M BCH (beware, signed integers, we lose 1 bit of precision), while a 18-bit shift will cap the maximal amount at 350k BCH, that is, 16 times less. While, it’s only a hunch, my take is that this numeric precision of a 14-bit shift would be sufficient to eliminate all int64 numerical overflows in finance calculations even when dealing with the budget of giant corporations. With, a 18-bit shift, edge cases would remain somewhat possible.
(1) Most Bitcoin wallets that exist today do not let you pay 1 satoshi. Instead, the minimal non-zero payable fee is 1 satoshi per byte. However, this behavior only reflects the implementation of the wallet, not a limitation of the Bitcoin protocol itself.
(2) Technically, there is a limit at 21M BCH, however, experts suspect that a few millions BCH are lost forever. Anecdotal evidence: I personally know one person who has irremediably lost about 100 BCH. Thus, those estimates sound right. In any case, even if those coins where not actually lost, it would not fundamentally change the discussion above.