You've already forked CHIP-MilliSatoshi
71 lines
5.3 KiB
Markdown
71 lines
5.3 KiB
Markdown
# Teams
|
|
|
|
The main document shows the main changes needed for this upgrade proposal, but it is hard to get a good overview what that means for a lot of the teams working in the BitcoinCash ecosystem from just that small, but central, change in the specification.
|
|
|
|
This document attempts (without claiming to be exhaustive) to capture how this affects the different teams. How the little change at the core may ripple out to all teams.
|
|
|
|
The main observation is that we propose to have two main wind-breakers. The protocol upgrade of the transaction-value will be made optional to users of the full node's RPC and by Fulcrum.
|
|
We propose that those two products keep their APIs backwards compatible as that is standard practice anyway. Only people that write support for milli-sats will then get the new numbers and they act like windbreakers because they protect the rest of the land from waves.
|
|
|
|
The milli-sats upgrade can then be divided into two waves. The first is the core infrastructure. Full nodes, basically. They are required to upgrade and people need to run a new version at the time of the upgrade in order to be able to follow the chain. The second wave is basically everyone else. The cost of not supporting milli-sats is very low for everyone else to the point that we can honestly say that people won't lose money while not supporting milli-sats. At least until the price of a single BitcoinCash rises very significantly.
|
|
|
|
**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.**
|
|
|
|
## Full Node
|
|
|
|
what do the full nodes need to do:
|
|
|
|
* the actual amount data structure would need to support this. Since several releases the team of BCHN has already encapsulated that integer to a more complex type, making such an upgrade a smooth fit. (https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/blob/master/src/amount.h?ref_type=heads)
|
|
* Using the transaction-version to decide how to parse the amount data-structure.
|
|
* The RPC today uses whole BCH's for value, so there is no change to the actual data.
|
|
But this may be a great moment to introduce (new!) bigInt based value-fields as
|
|
floating-point is notoriously bad for financial usage.
|
|
* The validation engine should account for milli-sats.
|
|
* The block-reward code should allow milli-sats deposited into an UTXO, but not claimed
|
|
by a spending tx to be counted.
|
|
* In the VM code the new opcode needs to be added.
|
|
|
|
## Middleware
|
|
|
|
In the cashtokens upgrade, Fulcrum introduced a great idea where a connecting client would indicate which API level it expects. A new API-level means that 'value' fields are then displayed in milli-sats instead of sats.
|
|
|
|
Middleware like Chaingraph and indeed Fulcrum can use this same approach to be backwards compatible while supporting the new feature in an opt-in manner. If they use that approach, a lot of teams will be very thankful as this means they do not need to upgrade until they are ready.
|
|
|
|
## Exchanges, explorers and other service companies
|
|
|
|
These teams generally do not use open source software, so we can't be entirely sure what their approach should be.
|
|
|
|
The chance of them using the standard RPC and electron services is, however, very high. And in that case these teams are exposed to a very small risk while not upgraded. Specifically, this is about receiving transactions which have milli-sats, but their tooling does not pick up on that. In which case a transfer will end up giving the rounding to the network as extra fees. Since a single satoshi would reach 1 cent in value only when the BitcoinCash price rises to a million dollars each we are talking about very small fractions of a cent that would fall through the cracks.
|
|
|
|
* Actually upgrading would imply making their internal systems aware of milli-sats.
|
|
* They would also need to start using the new APIs om the full node or electron servers.
|
|
|
|
## Libraries
|
|
|
|
The owner of the Flowee C++ libraries has pledged that these libs will include milli-sats support. This includes parsing of transactions and more.
|
|
|
|
The libAuth library is in need of adding support in some way since it has direct transaction-parsing code. Feedback from the owner is requested.
|
|
|
|
The rest of libraries we know about all use the APIs shown earlier, making their upgrade useful but not required.
|
|
|
|
## BitAuth (ide) / CashScript
|
|
|
|
These teams create valuable supporting tooling for developers to build next-gen transactions. Their users will eventually want to create transactions using milli-sats, in which case they need to support these new features.
|
|
|
|
Important to realize is that nothing will break if they do not upgrade, they just lack some features that their users might want to use.
|
|
|
|
## Wallets
|
|
|
|
Wallets are squarely in the second-wave of upgrades. Meaning they should be able to ship with
|
|
updated libraries or servers without much required change themselves before the upgrade. When
|
|
these wallets want to support the milli-sats feature they can add this on their own timeline.
|
|
|
|
* Flowee Pay uses the Flowee-libs, owner pledges to upgrade in time.
|
|
* Selene uses libAuth / Fulcrum.
|
|
* Paytaca: ?
|
|
* Cashonize: uses Fulcrum.
|
|
* Zapit (closed source): ?
|
|
* Electron Cash: Uses Fulcrum, [parses transaction](https://github.com/Electron-Cash/Electron-Cash/blob/6767a2fcb6f7b799812ed667e2b05de8f37b84c1/electroncash/transaction.py#L254).
|
|
* others ?
|
|
|