I'm designing the non-interactive transaction feature plus stealth address feature on node. First of all, we must agree that a Hard Fork will be there to make these features take effect from a block height. And then, an important "backward compatibility" topic comes here!
Gernally speaking, we can take advantage of the HF(Hard Fork) to break most of backward compatibility, simplify a lot of version handling issues, such as nodes compatibility (old version nodes will be splitted from the new version nodes network), wallets compatibility (old version wallets can not work with new version node), etc. Any backward compatibility need special handling on the version conversion which need extra efforts and complexity. Let's have a detailed list here:
- Suppose the HF node version will be v6.0, and the old versions are v4.x and v5.x.
- Suppose the HF will start from block height
768,000
or about 1 May 2021. (quite draft number here, to be changed.) - Nodes with v6.0 will build a new network, and all old versions (v4.x and v5.x) without upgrading will be kicked out of this new network. (This is also the Hard Fork meaning.)
- The fresh new nodes with v6.0 launched from scratch will join the new network only.
- The nodes upgraded from old version (v4.x or v5.x) are able to migrate local database into new version automatically.
- The block header since height
768,000
will take a new header version (version 3) for this HF. Block header data structure will not be changed in this HF. - p2p protocol version
4_000
will be used for this HF. All connection requests from lower p2p protocol versions (1_000
, etc.) will be declined.
v1
APIs (REST) deprecated and removed from version5.x
?.v2
APIs (Json-RPC) deprecated and removed from version6.0
.- Only
v3
APIs (Json-RPC) available in nodes with version6.0
.
- Suppose the HF wallet version will be
v6.0
formwc-wallet
,mwc713
andmwc-qt-wallet
. - The old version wallets are
v3.x
formwc-wallet
andmwc713
,v1.x
formwc-qt-wallet
. - The HF wallets
v6.0
will not work with old version nodes (with v4.x and v5.x). Warning and exit if connected to old version nodes. - The old version wallets (defined above at item 2) will not work with a new version node (
v6.0
and above). Warning and exit if connected to a node with versionv6.0
and above.
- Note: This behavior need a minor PR to integrate into current wallets release as earlier as possible, to have most of wallets upgraded before that HF date.
- The old version wallets without said PR will not warn and exit when working with new version node, but it will not work at all, both the scaning and sending/receiving doesn't work.
- Sending from old version wallets to
v6.0
HF wallets will not be received. More explain: Because the old version wallets only works with old version nodes, even this sending works (normally it does not), the final transaction will be posted only into the old version nodes, and the transaction will never reach the new HF network, the receiver will never receive the coins. The coins 'sent' will not be lost, because they are still there as unspent coins in the new HF network. - In any case, for receiving, it must stick to wallet confirmation before considering it as received.
- Sending from
v6.0
HF wallets to old version wallets maybe works, or maybe not, but the receiver has to upgrade his/her wallet to see these received coins. - A successful sending in
v6.0
HF wallets will not lose the coins, in any case the receiver is 100% able to collect the said received coins with his/her wallet seed secret.
- ? (TBC)
- ? (TBC)
okay, about mwc protocol version, a little bit investigation here:
So,
1000
has been released on 15th Sep.Check a running node and it shows that protocol version 2 and 1000 works well, no problem.
👍 understand now and thanks @bayk for the explain :-)
Yes. Before HF block height, we have to ensure
v6
wallet is compatible with old wallet, to get a smooth migration.Keep same slates format is a good idea for that.
And I would suggest to give a limited backward compatibility here, to avoid too much version handling workload and complexity. To be detailed when coming to wallet design part.