Massively simplify.

The multi-year approach solves the issue of sub-satoshi's getting lost, but since a single Satoshi is still quite cheap the solution is unneeded. We can just assume that such accidents simply pay a tiny tiny bit of money as miner fees.
2023-12-18 14:52:51 +01:00
parent 828898547e
commit 3241899e67
1 changed files with 34 additions and 55 deletions
@@ -1,13 +1,13 @@
-# CHIP sub-satoshi: how to get more zeros behind the decimal separator
+# CHIP 2024-sub-satoshi: increase accuracy in transactions
    Title: Sub-Satoshi storage of amounts
-    Type: Research (future!) for standards
+    Type: protocol upgrade
    Layer: All
    Maintainer: Tom Zander
-    Status: Research / Draft
+    Status: Draft
-    Initial Publication Date: not yet
+    Initial Publication Date: 2024-01-01
-    Latest Revision Date: 2023-04-03
+    Latest Revision Date: 2023-12-18
-    Version: 0.0.1
+    Version: 0.0.2
 <details>
@@ -16,12 +16,11 @@
 - [Summary](#summary)
 - [Deployment](#deployment)
 - [Motivation](#motivation)
 - [Benefits](#benefits)
 - [Technical Specification](#technical-specification)
 - [Prior Art & Alternatives](#prior-art-alternatives)
 - [Implementations](#implementations)
 - [Feedback & Reviews](#feedback--reviews)
- [Acknowledgments](#acknowledgements)
+- [Acknowledgements](#acknowledgements)
 - [Changelog](#changelog)
 - [Copyright](#copyright)
@@ -29,69 +28,49 @@
 ## Summary
-A method and approach to allow Bitcoin Cash transactions to have sub-satoshi's. In other words, more digits behind the separator.
+This proposal is a small change in transactions in order to allow us to move from 8 zero's behind the BCH number to instead have at least 3 more.
 ## Deployment
-This proposal requires multi-stage deployment for full nodes, wallets and likely all infrastructure.
+This is a minor protocol upgrade in the form of a new transaction version where a small change is needed in all places that interprets transactions.
 ## Motivation
-The original design that Satoshi put in place has the famous 21 million bitcoin as a maximum amount that will ever be in circulation. The rollout of the system has been less than flawless and it is estimated that Satoshi themselves already burned a million bitcoin. The move from BTC to BCH has likely left a lot of coins dead and forgotten as well.
+BitcoinCash follows the lessons from economics and this means that the total supply of coins ever created is limited. You probably heard the term, there will never be more then 21 million Bitcoin.
-If we look forward a decade or more, the chance of the world population to reach 9 or even 10 billion humans is not impossible.
+There are obviously a lot more people that are intended to use and own some Bitcoin and therefore there are 8 zero's behind the separator, each is called "a Satoshi". Leading to not 21 million but 
 two quadrillion one hundred trillion Satoshi. (21 e+14).
-All in all, the amount of smallest-indivisible-units that each human would have access to may simply be too little to allow Bitcoin Cash to become a world currency.
+While this is a lot, with a population of 8 Billion people that leaves only 2625,00 for each person on average. The actual for a lot of people will be a lot less as the wealth is not evenly spread and this raises the question if this can work as a world currency.
-## Benefits
+The idea of sub-Satoshis has come up before, 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.
-The idea, as tested in economics and concepts like stock-splits, is that we simply multiply the amount of money stored in any users wallet. Or, maybe easier to understand. We add a couple of digits behind the separator. Instead of owning $100.00, you now own $100.0000. Which is, exactly the same amount. But with more zeros behind the separator.
+The idea, as tested in economics and concepts like stock-splits, is that we simply multiply the amount of money stored in any users wallet. Or, maybe easier to understand. We add a couple of digits behind the separator. Instead of owning $100.00, you now own $100.0000. Which is, exactly the same amount. But with more zeros behind the separator. With more precision for sub-Satoshis.
-The benefit is that as the value rises due to Bitcoin Cash absorbing more and more of the worlds economy, it becomes possible to start giving out sub-satoshi prices or payments. We can also split the money over more people than before. Essentially it allows us to keep growing whereas otherwise the system may hit a glass ceiling where it simply can't on-board more people.
+The benefit is that as the value rises due to BitcoinCash absorbing more and more of the worlds economy, it becomes possible to start giving out sub-Satoshi prices for payments. We can also split the money over more people than before. Essentially it allows us to keep growing whereas otherwise the system may hit a glass ceiling where it simply can't on-board more people.
-### Multi-year approach
+# Technical Specification
-The nicest approach would be where we, overnight, change all the amounts of a person's wallet and multiply them by a factor. Lets assume 10 for now. Suddenly that person would not have 100 [units], but they would have 1000 [units] in their wallet. But at the same time the prices of anything they would buy is also multiplied by 10. Sound economic change.
+# Space for more digits
-The 'amount' field in a transaction is capable of expansion. We today use only 6 out of the 8 available bytes. So without any real changes to the transaction format we could simply change from one day to the next and it would work.
+The 'amount' field in a transaction is capable of expansion. It it an 8-byte number and after 33 halving we'd get 20 999 999.976 900 00 BCH. This, in Satoshi, is the same but without that dot. In absolute storage this is 6 bytes. Hex: 0x0000BEFE6F6399A8
-Except, naturally, in a decentralized system we need something a bit smarter. We can not change everything overnight. We need to do this in steps.
+What that means is that if 100% of all block rewards since the beginning of time end up in 1 transaction-output, the number in that transaction-output will only need 6 bytes to record the amount. The actual space reserved is actually 8 bytes. So we have space for more digits. Lets find out how much space we have.
-The simplest idea here is that we can use the transaction version. We can define that all transactions with version up until v2 have the current amount of 8 digits behind the separator. We then define that a transaction with version 3 will have all its values multiplied by 10. Which adds that extra zero behind the separator.
+To find out, we repeatedly multiply this huge number by 10, stopping when the total amount no longer fits in 8 bytes, we get to the following outcome:
 The effect of such an approach is what we want, a gradual changing of all of the value on-chain as people spend that money with v3 transactions. The only downside is that we can likely never drop support for the pre-v3 transaction-type.
 We can take a multi-year approach to make the roll-out happen smoothly because it is not just full nodes but all sending and receiving wallets that need to support this in order for it to work.
 What we can do:
 1. We forbid the network from accepting transactions with versions higher than 2. (done in May 2023)
 2. We introduce version 3 transactions. Making full nodes process them with their extra zeros behind the separator.  
   The full nodes, however, do NOT allow those extra digits to be anything but zero. This allows transparent conversion between v2 and v3, but also to allow it to go back lossless.  
   The point of this phase is to allow new wallets to build v3 transactions, but go back without loss to a v2 transaction if a receiver requests that.
 3. Full nodes remove the restriction on usage of the new digits, we expect all wallets to support v3 by this point.
 As pointed out, we can never move to stop supporting v2 transactions on full nodes as it is impossible to say if all stored money that may be used in future has been converted. Wallets, on the other hand, benefit from the decentralized world. Some wallets may support older transaction types, some may not and users just pick and choose. A wallet can simply stop supporting older transactions when their users no longer spend any v2 transactions.
 ## Technical Specification
 The 'amount' field in a transaction is capable of expansion. It it an 8-byte number and after 33 halving we'd get 20 999 999.976 900 00 BCH. Or, in Satoshi, the same but without that dot. In absolute storage this is 6 bytes. Hex: 0xBEFE6F6399A8
 So if we repeatedly multiply by 10, stopping when the total amount no longer fits in 8 bytes, we get to the following that is possible:
 * An extra 3 digits behind the separator.
-* The blockreward doesn't stop after 33 halvings, but after 42.
+* The block reward doesn't stop after 33 halvings, but after 42.
-* The extra blockreward add a total of 0.02307 BCH to the entire supply.
+* The extra block reward add a total of 0.02307 BCH to the entire supply.
 The total amount is then 2099999999997060000, or in hexadecimal: 0x1d24b2dfac2523a0
 <details>
 <summary><strong>Supply Era's</strong></summary>
 A [simple program](supply.cpp) can do the math. Below is the output:
-Todays reward schedule:
+Today's reward schedule:
 | Era | Added in Era | Total supply |
 | --- | ---| ---|
@@ -147,24 +126,24 @@ New schedule from the point where the previous would hit zero, and with everythi
 </details>
 This 1000x is us limiting ourselves based on the assumption that 100% of all BCH ever minted should still be possible to store in a single transaction-output. It should be noted that since this is never actually going to happen in practice, a further 2 zero's should be easy and mostly safe to add. But the complexity in the full node might go up as a result.
-Practically speaking there is no known case where the entire possible supply will ever be in a single transaction utxo, as such we could theoretically add even more zeros, but the author doesn't see that as needed and better safe than sorry.
+## New transaction version
-In transactions we determine the value based on the original transaction-output. This is the case today, that will change slightly for version 3 transactions.
+In the May 2023 we introduced the protocol rule that transaction versions not known to the network are not allowed. This gives us a good opportunity to allow users to use the transaction version as an indication that something is to be used slightly different again. Similar to how this is happening with version 2 transactions and BIP68.
-The effective amount can be calculated by simply taking the value encoded in the output of the transaction, and when the transaction version is older than 3, the amount is multiplied by 1000 before being processed further.
+For transactions that are marked as version 3 or later, the 'amount' field in each output is to be interpreted as being a number that includes sub-Satoshis.
-To put this in an example: a transaction of type v3 spends some UTXOs and creates a new UTXO. To calculate what the value is on incoming transactions we need to look at the transaction-version that created that UTXO is. If its older than 3, the amount needs to be adjusted before being processed.  
+Payments from a version 2 (or earlier) transaction-output to a version 3 (or later) transaction-output will thus convert the amount by multiplying it with 1000. And vice versa.
 Similarly, when creating the new transaction outputs the wallet or full node refers to the version of the current transaction in order to determine the conversion there.
-This way the transaction versions can be freely mixed and no funds will get lost.
+A version 3 transaction can thus split an amount in sub-Satoshis among its outputs, should it wish to do so. The monetary value of a single Satoshi is so low that doing this in the 2025 upgrade is advised in order to make transactions maybe losing sub-Satoshis if they go back to version 2 transactions accidentally to be a non-event that simply increases the miner fee a tiny little bit. The ability to be backwards compatible at low cost with old transaction generators this way is likely quite valuable.
 ## Implementations
 This is a 'research' level document, the idea good enough to write down but its not really ready to be made into an actual proposal yet simply because the need for this is so far in the future.
 ## Feedback & Reviews
 ## 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.
 ## Copyright
 Copyright (C) 2023 Tom Zander