Add part about script

readme.md

@@ -37,7 +37,7 @@ BitcoinCash follows the lessons from economics and this means that the total sup
 
 There are obviously a lot more people that are intended to use and own some Bitcoin than 21 million and therefore there are 8 zero's behind the separator. A single unit is called "a Satoshi". Leading to not 21 million but two quadrillion one hundred trillion Satoshi. (21 e+14).
 
-While this is a lot, with a population of 8 Billion people that leaves only 2625,00 for each person on average. The actual number of Satoshi for many people will be a lot less as wealth is simply not evenly spread and this raises the question if this can work as a world currency. A single Satoshi would be worth a lot of coffees and breads.
+While this is a lot, with a population of 8 Billion people that leaves only 2625.00 for each person on average. The actual number of Satoshi for many people will be a lot less as wealth is simply not evenly spread and this raises the question if this can work as a world currency. A single Satoshi would be worth a lot of coffees and breads.
 
 The idea of sub-Satoshis is not novel, it is the simple concept that instead of a bread costing $4.00 it overnight changes to cost $4.00000. Which is actually exactly the same amount, but with extra precision.
 
@@ -134,8 +134,46 @@ Payments from a version 2 (or earlier) transaction-output to a version 3 (or lat
 
 A version 3 transaction can thus split an outputValue in sub-Satoshis among its outputs, should it wish to do so. The monetary value of a single Satoshi is still low enough that this upgrade is aimed for the May 2025 slot in order to make transactions maybe losing sub-Satoshis if they go back to version 2 transactions accidentally to be not be costly. It would simply increase the miner fee a tiny little bit. The ability to be backwards compatible at low cost with old transaction generators this way is valuable.
 
+## Scripting
+
+Money on BitcoinCash can be unlocked and transferred only when a specific [predicate](https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/) is affirmed to be true. The predicate is expressed in "Bitcoin Script" and parts of it are relevant to the Sub-Satoshi proposal since in 2022 BitcoinCash added the  [Native Introspection](https://flowee.org/docs/spec/forks/native-introspection/) scripting-opcodes. The relevant [instructions](https://flowee.org/docs/spec/blockchain/script/#introspection) range from `OP_TXVERSION` to `OP_UTXOVALUE` / `OP_OUTPUTVALUE`.
+
+A predicate locking funds with some test based on value-transferred today operates on the smallest unit called Satoshi's. Scripts could be written to check transaction value and adjust, but that does not sound very safe. Consider a case where a predicate is written to only allow moving of funds in a transaction that has a bigger output than it does an input. Additionally it forces the same predicate-script to be present on the next transaction. This is possible today, but would fail if between one and the next transaction the funds would suddenly have a multiplication factor of 1000.  
+Which means that the script should actively choose to use sub-Satoshis.
+
+Consider also the various math operations we have today, since 2022 we [use 64-bit math](https://flowee.org/docs/spec/forks/bigint/). While that is a very signification widening of range, some scripts may prefer to use the old style `Value`, in full Satoshi's, in order to avoid overflows due to large amounts.
+
+The [Bigger Integers CHIP](https://flowee.org/docs/spec/forks/bigint/#limiting-arithmetic-operations-to-8-byte-script-numbers) goes into some detail on this topic too claiming that basic operations should be OK and multi-step math may be needed.
+
+We introduce `OP_SET_VALUE_MODE` a new opcode with code-point `0xTODO` that switches between Values with 8 digits behind the full unit and 11 digits.
+
+
+| Operation        | Codepoint         | Description                                          |
+| ---------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| OP_SET_VALUE_MODE | `0xff` (-1) | Pop the top item from the stack as an enum-index. Change the VM-wide conversion for usage of `OP_VALUE` and 'OP_OUTPUTVALUE'. 1: Sats. 2: SubSats |
+
+
 # Feedback & Reviews
 
+# Discussion
+
+## more digits
+
+This specification explains why we can safely get 3 extra zero's with no real downsides in our software stacks.  
+The rationale there is based on the total issued supply of sats, however. Which will never be seen in practice on a single output, or even a single transaction.
+
+It is fair to say that 1% of all coins will never be on a single input or output and as a result we could be mostly safe about adding an additional 2 digits for nearly free. It fits in the same 8 byte number, as long as no more than 1% of total issuable supply never ends up on a single UTXO.
+
+The owners personal opinion is that in the far future if this is deemed needed and safe, we can simply do it then. Same trick with a new transaction version, but 50 years from now. We'd even be able to reuse the opcode and simply add an extra enum value.
+
+## Why not wait?
+
+The obvious question that comes up is based on today's price and the absolute value of a single Satoshi being so low that we don't expect we'll need this for quite some time. So, why not wait until we actually need this?
+
+It is a fair question and there are various answers to this. First, today's M2 (circulating money supply in dollars) was in March 2023 about the same (in dollar-cents) as the amount of Satoshi's are in BitcoinCash. Having an optimistic outlook on the world economy means that on a long enough timescale we are very likely to actually need the added accuracy.
+
+This proposal uses the fact that a fractional-Satoshi is practically free as an advantage. While the loss to a user is near zero going from a transaction with sub-Satoshi to one without, there is much less push for the entire ecosystem to rush to support this. And that makes the upgrade cheaper. When the price goes up 1000x, the cost of enabling this upgrade also becomes somewhat more expensive.
+
 # Changelog
 
 At the end of 2023 the proposal was massively simplified after realization that some problems that were solved with the extra complexity was a non-issue in practice. Check git if you're curious.
@@ -145,4 +183,3 @@ At the end of 2023 the proposal was massively simplified after realization that
 Copyright (C) 2023 Tom Zander
 
 Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
-