I want to chime in on this CHIP since it came up yesterday on the BeCash and Chill Twitter space.
Overall, this is a good idea imo
First off, I’m in full support of this CHIP being targeted for the 2025 upgrade cycle (Nov 2024 lock-in). I don’t really see any reason NOT to introduce sub-satoshis, especially if it is at neglible cost as this CHIP suggests. Simply using the rest of the byte space we have available to us already seems incredibly sensible; perhaps Satoshi thought ahead in this regard?
I see major benefits to enabling sub-satoshis (going forward I will call these “millisats,” explained below):
-
As noted in the CHIP, if all bitcoins were distributed evenly across the human population, that only leaves ~2625 sats per person. In this scenario, the value of a single satoshi would likely be higher than many common goods and services. Having 2,625,000 millisats per person in circulation instead will allow significantly more robust pricing for the world’s economic activity.
-
In addition to #1, millisats would better facilitate on-chain micropayments. I anticipate that in a future bitcoinized economy, there will be lots of value that can be derived and earned from an emergent “micro-economy.” I would expect such a “micro-economy” to function in some parts similarly to the way platforms like Twitter and Facebook pay their users a portion of ad revenue generated by their audience’s engagement. In other words, in a proper p2p, decentralized economy, many new forms of income generation become possible by realizing multiple/high-volume microtransaction streams.
May 2025 rationale
I also agree with the rationale for deploying in May 2025: there’s (ostensibly) negligible cost, reasonable benefit even today, and the costs increase as the value of BCH rises due to the millisat->sat conversion issue.
My two millisats on the implementation details
As far as implementation, based on the discussion here, a dedicated OP_BIGNUM_MODE seems to be a better solution than a new tx version. However, versioning the VM itself also seems like a potentially good idea - probably better than some ${flags} OP_SETSTATE. In this case I’d imagine an opcode like ${version} OP_ENV, and then the protocol would enforce VM behavior for each version. This would allow all scripts deployed previously to some upgrade to be guaranteed to have predictable behavior, as it would explicitly set its own execution context in the locking bytecode. The use cases proposed by bchautist seem like reasonable rationale for this approach.
The only downside to the OP_ENV approach that I can think of is that it may increase the computational costs of transaction validation… but in practice, we can benchmark this. A conditional like this should be cheap, I think… but I don’t actually know for sure 
Regardless of which opcode we end up going with, it seems sensible to reject any transaction that uses the opcode more than once, or outside of script initialization, in order to ensure the script behaves predictably.
On “millisats” and the Sats Standard (Ꞩ)
During the BeCash and Chill space yesterday, we came up with the idea of standardizing “sats” (Ꞩ) nomenclature like so: https://twitter.com/kzKallisti/status/1765837741177155848
'Sats Standard (Ꞩ)' denominations from 'millisat' to 'petasat'
Sats Standard (Ꞩ):
1 sat = 0.00000001 BCH
1 BCH = 100,000,000 sats
1 millisat = 0.001 sats (sub-satoshis)
1 sat = 1 Ꞩ
1000 sats = 1 Kilosat
1000 Kilosats = 1 Megasat = 1,000,000 sats
100 Megasats = 1 BCH = 100,000,000 sats
1000 Megasats = 1 Gigasat = 10 BCH
1000 Gigasats = 1 Terasat = 10,000 BCH
1000 Terasats = 1 Petasat = 10,000,000 BCH
2.1 Petasats = 21,000 Terasats = 21 million BCH = 2.1 million Megasats
Going forward, I will likely start using these denominations myself, even prior to the implementation of millisats.
The Fee Problem
While nodes currently will not relay any transaction with a fee less than 1000 sats/kB (1 sat/byte), this parameter is trivial to change on the node level, and miners can directly accept transactions with any fee rate they wish.
If social consensus agrees that fees on BCH should not exceed something like $0.10 (2024 USD), it’s inevitable that 1 sat/byte will not be able to deliver that promise. 1 sat per USD is a price of $100,000,000 USD/BCH. That would make $546 USD the smallest transaction possible at 1 sat/byte due to dust limits, and the fee to do so would be ~$219 USD.
Measuring fees in millisats is the only way to alleviate this. At 1 millisat per byte (1 sat/kB), the minimum transaction amount becomes $0.546 USD and the fee becomes $0.219 USD instead, which is significantly closer to the fee rates we expect on BCH.
Unfortunately, this still exceeds our arbitrary $0.10 USD desired fee threshold, but we can also reasonably expect that by the time we are measuring fees in millisats, $0.10 in 2024 USD will probably be something more like $1.00 in 2036 USD.
Some napkin math on miner revenue at these levels:
Assumptions:
BCH price: $100,000,000 USD/BCH
Fee threshold: 1 millisat / byte
2-in-2-out P2PKH transaction size: 360 bytes
Max blocksize: 256mb
Calculations:
Max transactions per block: 711,111
Fee earned per block: 255,999,960 millisats (~256 kilosats)
USD per block: $255,999.96
Conclusion: a mere 1% of the population making 1 transaction per day nets nearly $37 million USD in daily miner revenue; introducing millisat fees should not significantly disrupt mining operations at scale. Market forces will dictate the appropriate fee rate as miners will accept transactions that utilize their resources (blockspace) most efficiently. Having empty blocks due to restrictive/user-inaccessible fee rate policy is bad business.
