Backward Compatibility

backcomp.md

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:

node backward compatibility

1. Suppose the HF node version will be v6.0, and the old versions are v4.x and v5.x.
2. Suppose the HF will start from block height 768,000 or about 1 May 2021. (quite draft number here, to be changed.)
3. 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.)
4. The fresh new nodes with v6.0 launched from scratch will join the new network only.
5. The nodes upgraded from old version (v4.x or v5.x) are able to migrate local database into new version automatically.
6. 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.
7. 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.

node API backward compatibility

1. v1 APIs (REST) deprecated and removed from version 5.x?.
2. v2 APIs (Json-RPC) deprecated and removed from version 6.0.
3. Only v3 APIs (Json-RPC) available in nodes with version 6.0.

wallet backward compatibility

1. Suppose the HF wallet version will be v6.0 for mwc-wallet,mwc713 and mwc-qt-wallet.
2. The old version wallets are v3.x for mwc-wallet and mwc713, v1.x for mwc-qt-wallet.
3. 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.
4. 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 version v6.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.

send/receive between old version wallets and v6.0 HF wallets

1. 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.
2. In any case, for receiving, it must stick to wallet confirmation before considering it as received.
3. 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.
4. 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.

wallet API backward compatibility

mwc-wallet APIs

1. ? (TBC)

mwc713 APIs

1. ? (TBC)

Thanks @MyCryptoT for your comments 👍 We will also take care of these.