I had the same idea in the previous iteration (see git log).
The thing that changed my mind on that is that currently the economic value of sub-sat is negligible. And that is a benefit for the upgrade path.
It means that an incoming v3 transaction (with maybe some sub-sats) can cheaply be converted back to a v2 transaction (because that vendor hasn’t upgraded something yet?). And the only loss is the rounding of the sub-sats to sats. It can go to the mining fee.
Which is to say, this upgrade is going to get more expensive as the price rises.
Earliest we can plan this for is May 2025 anyway, which is 18 months away and with the market today we could be looking at much increased prices already by then. Or the same as today, but since we need to look far ahead with such a change I’d rather err on caution and avoid losing the window of opportunity.
This too I was thinking, but in reality this is almost never actually an issue. Realize that a standard var in JS can store all sats ever created (21 e+14). Which obviously will never actually be used in 99% of the codepaths because all those sats are not going to be on a single output or input. Or even a single transaction!
So with 1000x you limit yourself to (quick dumb math) about 21000 BCH being able to fit in that ‘double’ (or JS var). Which is enough for practically all normal usecases. Sure, anyone making libraries and specialistic software like wallets needs to take care and focus on using bigint. But I’m merely pointing out that the pain is a lot less than expected.
I recall that testnet3 had plenty of random version numbers, no clue about testnet4.
The mainnet tests we did back when the check was made showed a very low number of them. Will have to re-run that.
My initial response is that to avoid tech debt we ideally drop the concept of ‘sub-sats’ as soon as software is over to the new setup. We then simply have more satoshis and that will make all software much easier to manage for the next 100 years.
With that in mind, my ideal is that the transaction version is a flag on how the script unlocking that money is interpreted.
Is the VM verifying a predicate unlocking money held in a 3+ UTXO, then
OP_*VALUE gives the ‘subsats’ amount, otherwise it gives the ‘sats’ amount.
Which has the advantage that there is no trucation going to happen, as that sounds dirty to my ears.
This gives people the time for scripts to get verified to work on sub-sats before being deployed on v3 transaction predicates.
For the people more at home with scripting, how does that sound?