Can you give some examples?
For reference, this page (part of the CHIP) shows some background.
Choice quote:
In other words, if we do this correctly then the vast majority of teams need to do nothing until they are ready to support this feature. Which may be in several years.
Youâre right, I was reminded of this the same day you wrote it, when I was updating my AnyHedge indexer from ChainGraph to node RPC.
ChainGraph was returning sats and I was consuming sats, and RPC returns BCH, and I was actually annoyed by that when I was switching hah, and it got me thinking how I can safely just mul with 1e8 and round because the double canât exceed the max. number of digits due to 21M BCH supply.
With fractional sats, representation as double would not always be exact since a double can safely hold a maximum integer value of 9007199254740991 which would mean values greater than 90,071.99254740991 BCH would be imprecise if handled by software using double precision.
Yeah I donât see a need to rush it, but we can still move towards it by working out the technical nits, building out the CHIP, and having it all ready to roll when time comes. Whatâs stopping software from getting ready now to parse a hypothetical new TX format ahead of time? When we locked TX version, we locked it precisely because maybe one day we might need to use it to switch something.
Moving ahead is great! Pushing for 2025 is an absolute no-go for me, barring appearance of some miraculous incentive to make it necessary.
Also I think we will need 128 bit integers if we are going for subsats. 64 bits is already a tight jacket.
That sounds like a terrible idea. Since this CHIP is still in an early stage a piece of software that locks in the currently proposed functionality would severely misbehave if the CHIP would change and version=10 gets a different meaning. I would recommend any software that parses raw transactions to produce an error if it encounters any transaction with version>2 (possibly with exceptions for those old transactions with other versionsâŚ) and only add support for other versions once corresponding CHIPs are locked in.
Yeah this, just get ready for the possibility that the TX version might be upgraded in some unknown way and have a plan on how to handle it.
Some seem to fear that if one upgrades, everyone needs to upgrade.
This is a good thing to talk about. What we propose is to make it completely invisible for anyone outside of the full node team to even realize that this milli-sats transaction has been sent.
This means that indeed if I sent a v10 transaction to the paytaca wallet, the only effect will be that they will not notice the sub-sat value. When they spent from it as normal, the effect will be that the milli-sats will end up being added to the fees paid.
Similarly,
if a user creates a v10 transaction and re-uses a script that is now using 64bit math, that script will not actually see the milli-sats. Even though they are present on the transaction itself, the switch to get the miillisats is a decision INSIDE the script.
This means that if youâre not certain 64bit math and milli-sats will work together for your usecase, you probably want to push for a 128bit math upgrade and wait for that before you start using milli-sats.
Just because millisats are available on the bitoincash, doesnât mean you need to use it.
Just because someone may send you a v10 transaction with milli-sats, doesnât mean you are forced to consume it.
That is a good idea, we even have it as a consensus rule for some time now.
I suggest to have a cut-off at version 9, thatâs safer.
Just for clarityâs sake, granted this is all hypotheticals, $100,000,000 per coin isnât really in the cards (without some major inflation, which maybe is in the cards in the next 10-20 years!), but is still a bit irrelevant.
There is approximately $49T in the M1 money supply and $83T for M2. Rounding to $50T and $100T nets a price of BCH at $2.38M and $4.76M, respectively. So the fee would be $7,000 or $15,000, roughly (respectively), rather than $255,000.
Though, inflation doesnât matter, because the actual value of the currency wouldnât change.
So for todayâs value, an adjusted calc would beâŚroughly $12,000 per block in todayâs dollars. And that value should scale up proportionally with inflation, whereas value would remain constant.
1sat/byte, assuming the $4.76M price per BCH, would be a fee of $17. Which in todayâs dollars would still be far too expensive. So 1millisat/byte does make sense to keep the fee at just around 1 penny.
So at the end, the daily fee to miners would only be $1.7M (in todayâs dollars) of value. But the beauty is that thatâs only at 1%, and assuming no improvements are made to transaction sizes! So there should never really be a fee problem at scale.
EDIT:
For fun calc with todayâs dollars/value in a full replacement scenarioâŚ
60,000tps * 60seconds * 10min * 360bytes/tx / 100,000,000,000millisats/bch * 4,760,000price/bch * 144blocks/day = $88.8M in daily miner fees!
That should be plenty of fee budget.
EDIT: Amount of daily storage needed at the above scale:
60,000tps * 60sec * 60min * 24hr * 360 bytes/tx = 1,866,240,000,000 bytes = 1.866TBytes Per day (or 1.738Tibibytes per day).
Maybe little by little Iâll break it down as I get bored, but some more assumptions!
Today, Seagate has a 30TB HDD (plans to retail for $450 iirc). So $450 will cover 16 days of transactions. Letâs say there are 100 mining pools. Thatâs $450 / 16 days * 100 pools = $2,800 per day for all mining pools! Doesnât even make a dent in the daily mining fees. Except, that dent will become smaller over time as storage gets cheaper and cheaper in relative value.
The natural counter to this would be (fast storage is needed!). Ok, well 100TB SSDs exist today (in 3.5in form factor), but they cost $40,000. Letâs do that math:
$40,000 / 53 days * 100 pools = $75,000 â 0.08% of the daily mining revenue. This is basically non-existent.
But at the same time, if you canât be bothered to spend THAT much, Run HDDs in RAID 10. Sure, now paying for extra drives, but the relative cost (to daily revenue) is still basically non-existent. Now you have fast, redundant storage, at a fraction of the cost.
Heck, letâs do those 100TB drives in a RAID 10 configuration. Double that cost for the SSDs! 0.16% of daily mining fees. Now this is where it becomes noticeable, but it is still so tiny. And this is before accounting for the decrease in relative cost for this storage, which would likely send this cost down 10x by the time 60,000tps would ever occur.
Now letâs think about internet bandwidth. 1.866TB / day. 1.866TB / 24hrs / 60min / 60sec = ~24MBps = ~ 200Mbps. Thatâs pretty close to a normal home internet connection today. Associated costs are completely insignificant.
Then what about for businesses/otherwise running nodes? I donât really think itâs necessary to account for their cost since UTXO commitments will likely exist well before this sort of scale.
What about other high performance full archival nodes? Such services would be offered and likely charge for those services. They will charge what the market determines it is worth so this is not really a consideration.
Whatâs the TLDR?
60,000tps with a 0.001sat fee at $4.76M relative value per coin equates to $88.8 million of relative miner compensation a day.
This requires a daily incremental cost (over 0) of 0.16% of those fees assuming a high performance configuration.
Necessary uninterrupted internet connection would be 200Mbps, which is common today for homes and so this is completely insignificant.
As adoption grows, so will the costs. But I donât disagree at all with what youâre saying.
Just for curiosityâs sake, would there be a scenario where rather than changing sats, we could piggy back off of CashTokens and basically create a âcentoshiâ? Kind of like we have dollars (BCH) and coins (centoshis) â Not sure how to do this without a central body⌠maybe it would need some kind of decentralized bridge to do this⌠like a BCH stablecoin that stabilizes BCHâŚon BCH?
This contains good ideas for brainstorming and it sounds like the discussion succeeded in uncovering some hidden complexity.
The question the authors are asking is âWhat needs to be done now to ensure we can support more granular transactions in the future, if and when we need them?â
Wonât doing 128Bit math without actually having 128bit processors be very CPU-intensive?
There are libraries that do this, but the math is not done directly using CPU instructions as usual, but is âsimulatedâ, like running not-supported software using an emulator.
Honestly I have no idea how computationally expensive it would be in effect. Maybe the overall load is so small nobody would notice.
In short, yes.
Multiplications are one of the most CPU intensive things to do and a 128 bit multiplication on a 64bit CPU will be emulated with 2 or 3 such instructions. (Karatsuba algorithm - Wikipedia)
Iâm absolutely certain weâll get it natively, though. x86 architectures are in the last phase. Apple is now competing with an entirely new design and the Intel / AMD /etc will have to move over to these new architectures to compete. Will probably take 10 years, though.
There is a pretty good chance that in that time the CPUs will go to 128bit. Simply because its 1000x times easier to do on a much more modern architecture and partly because it is competitive.
So, my personal preference is to wait for the CPUs to do it. But that wish is entirely based on the fact that I have no pressing need for the feature. When we went to 64 bit that pressing need didnât exist either, we talked about it at length back then.
Going 128 bits will be much more disruptive than going 64bit, so I hope we can postpone it a bit longer. And likely use the OP_ENV idea to actually move over safely.
Not on Linux.
Usually going from one architecture to a higher architecture is very easy, since all you need to do is recompile things.
And SPV wallets on Android can just do the simulated computation. Wallets donât really do a lot of computations to begin with, so this should be straightforward.
âŚand who runs their business/production nodes on Windows these days? Nobody.
the context of that statement was about the scripting langauge in BitcoinCash. Specifically about making multiplications done in the VM use 128bits instead of the standard 64.
It will be more disruprite for the simple reason that on the 32-bit setup the amount of math-using scripts were quite low. They didnât really do anything interesting.
The current 64bit engine for BitcoinCash opened up a LOT of extra options. And it is impossible to know if those scripts will handle 128bit well. We simply canât know since we canât see the scripts until they are successfully spent.
This is why I wrote it will be a lot more difficult to do. Because I start with the assumption (stolen from the Kernel): we will never break user-space.
Unless theyâre relying on overflow to fail the TX (which the CHIP explicitly discourages), theyâd be fine.
Notice of Possible Future Expansion
While unusual, it is possible to design contracts which rely on the rejection of otherwise-valid Script Numbers which are larger than 8 bytes. Contract authors are advised that future upgrades may further expand the supported range of BCH VM Script Numbers beyond 8 bytes.
This proposal interprets such failure-reliant constructions as intentional â they are designed to fail unless/until a possible future network upgrade in which larger Script Numbers are enabled (i.e. a contract branch which can only be successfully evaluated in the event of such an upgrade).
As always, the security of a contract is the responsibility of the entity locking funds in that contract; funds can always be locked in insecure contracts (e.g.
OP_DROP OP_1). This notice is provided to warn contract authors and explicitly codify a network policy: the possible existence of poorly-designed contracts will not preclude future upgrades from further expanding the range of Script Numbers.To ensure a contract will always fail when arithmetic results overflow or underflow 8-byte Script Numbers (in the rare case that such a behavior is desirable), that behavior must be either 1) explicitly validated or 2) introduced to the contract prior to the activation of any future upgrade which expands the range of Script Numbers.
This is why I said that my assumption is that we should not break userspace. And I referenced kernel for a reason.
Because people WILL go against the suggestions made. Even moreso since I suspect that this suggestion is not actually shown in the docs for cashscript. Just in the CHIP. Which nobody reads after the activation.
So, while I completely agree people should really not be doing that, this isnât a crashing app on Linux, this is about people losing access to their money. And there are going to be a LOT more scripts using math on-chain since we actually made it useful for a lot of usecases. A percentage of that will do stupid stuff. Fact of life. Downside of success.
And breaking âuserspaceâ in kernel is super annoying, but in BitcoinCash is makes people lose actual money forever. Iâm just saying, we should be extremely reluctant and indeed do well to weigh all the options. OP_ENV being a winner in my book so far.
Itâs October 2024 now and it looks like weâre going to get BigInt! 
This is just false, the supply would stay the same, but thereâd be a decimal point and 3 zeroes after it, so
2,100,000,000,000,000.000 satoshis (last separator is a period)
or
2,100,000,000,000,000,000 subsatoshis (last separator is a comma)
problem is that non-upgraded software would mistakenly mix them up
The CHIP explains this:
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.
If you are saying this, this means your technical competence is insufficient to comprehend what the CHIP-subsatoshi will do.
It would be beneficial to everybody, including you, to cease to post in this manner.
Unfortunately, complete nonsense, none of these things can or will happen.